Maybe because I am out of loop with web development, but this sounds like a huge change to me. So instead of HTML elements, there will be just one big element, and everything will be rendered there? How will text selection work for example? Will Google Docs basically implement a GUI library like GTK, which renders everything itself, but for the web?
I'm not sure but what you are suggesting is not outside the realm of possibility. There are already projects like https://makepad.dev/ which implement their GUI on top of WebGL. (Which is arguably more challenging than implementation on top of Canvas 2D.)
Google Docs will now use canvas based rendering
661–670 of 953 posts
Re: Google Docs will now use canvas based rendering
#662My understanding of canvas is that it’s a 2D bitmap you can draw to. So how is text selection (and a keyboard up in mobile Safari) working here? Do they have hidden text elements behind the canvas or something?
Re: Google Docs will now use canvas based rendering
#663Earlier quoted context omitted.
So, because you don't want binary blobs to be deployed over the web, you would like users to download and install binary blob native applications... And that makes things better in what way, for whom, exactly?
I'll bite. For starters, a binary blob on your computer can be prevented from "phoning home" to collect personal data much more effectively than a web app can. Additionally, the vendor is often forced to compete with their own old software because they can't always force you to run the newest binary blob. This prevents the wholesale loss of features from products you rely on at the whim of the vendor.
In theory, it can be. In practice, the average user doesn't do a damn thing to do so, and installing a random native blob from the internet is far more dangerous than a webapp running in a browser sandbox.
> Additionally, the vendor is often forced to compete with their own old software because they can't always force you to run the newest binary blob.
This is also how we get people running years-old software instead of deploying security patches.
I understand that a power user may prefer these trade-offs. Most users are not power users.
Re: Google Docs will now use canvas based rendering
#664Earlier quoted context omitted.
> I imagine using canvas gave them a lot more flexibility in addition to being more performant. I'm perplexed because I don't expect canvas rendering to be faster - or necessarily more flexible - because the web is document-first: HTML and CSS were/are all built-around describing and styling textual content , and computer program source code files are invariably all textual content files. So while browsers all have h…
>I'm perplexed because I don't expect canvas rendering to be faster ...yet it is. Really. Even though DOM paths are heavily optimized, they are extremely flexible, and that flexibility creates a wall in possible performance optimizations. In a context like word processor, precision is more important than your regular website (and across browsers!) so you end up implementing little hacks everywhere, pushing half a pix…
https://meetingcpp.com/mcpp/slides/2018/Data-oriented%20desi...
Re: Google Docs will now use canvas based rendering
#665Re: Google Docs will now use canvas based rendering
#666Earlier quoted context omitted.
Yeah that was our primary risk - the actual main.dart.js file becoming too large. We host the JS asset on Cloudfront and the web app from somewhere else, which makes it much better. As far as Flutter Web itself, I only think it became production ready for the web in the last 3 months - literally! It was a bit of a risky choice, but it worked out well for us.
I'm glad it worked out! It's a nice framework to work with, and Dart is a pleasant language. How big is your bundle size atm, if I might ask?
Re: Google Docs will now use canvas based rendering
#667Earlier quoted context omitted.
I don't understand why stupid people downvote my comment. I just posted a link. Why are you so dumb?
Your link was fine, and has since been upvoted (see https://hn.algolia.com/?dateRange=all&page=0&prefix=true&sor... ), but a comment like this one breaks the site guidelines. Would you mind reviewing them? https://news.ycombinator.com/newsguidelines.html Edit: could you please stop posting unsubstantive comments generally? Your account has been doing a lot of that, and we're hoping for a little higher quality of disc…
Re: Google Docs will now use canvas based rendering
#668Earlier quoted context omitted.
I've been coding Flutter mobile apps for a couple of years, but have only toyed around with the web target. In my experience it seemed kinda off . Scrolling lists ignored my native scroll speed and janked, text manipulation felt laggy, etc. It reminded me of the good old horrible days when Flash-based websites was widespread. I tested it right after the 2.0 release, so perhaps they've fixed it since. EDIT: Also IIRC…
>seemed kinda off Yes. And that's exactly why it's important for Google to eat their own dogfood.
Re: Google Docs will now use canvas based rendering
#669In 2009, I joined Mozilla and started working on the Bespin[1] project, which Ben Galbraith & Dion Almaer had brought to Moz. Bespin was built with a canvas-based renderer. Bespin was way faster than other browser-based code editors at the time. Then the Ajax.org/Cloud9 folks came along with their Ace editor[2], which was DOM-based and still very fast. We ended up merging the projects. edit to add: and switching to D…
For those unfamiliar, the XUL tree is a performant 1990s-era virtualized list that is able to render millions to tens of millions of rows of content without slowdown since it gives you the option of rendering internally in Firefox rather than through the DOM.
I still don't completely understand why Mozilla is/was planning to axe[1][2] it since there's no web-based HTML5/JS replacement (the virtualized "tree" is implemented in C++, iirc) and it's still being actively used in places.{xul/xhtml}[3] and the Thunderbird/SeaMonkey[4][5] products.
It's interesting that both Google's canvas bet (Flutter, Docs, etc.) and the Mozilla XUL tree are basically trying to solve a nearly identical problem (DOM nodes are expensive and DOM manipulation is slow) ~20-25 years apart.
[0]: https://developer.mozilla.org/en-US/docs/Archive/Mozilla/XUL...
[1]: https://docs.google.com/document/d/1ORqed8SW_7fPnPdjfz42RoGf...
[2]: https://bugzilla.mozilla.org/show_bug.cgi?id=1446341
[3]: chrome://browser/content/places/places.xhtml
Re: Google Docs will now use canvas based rendering
#670In 2009, I joined Mozilla and started working on the Bespin[1] project, which Ben Galbraith & Dion Almaer had brought to Moz. Bespin was built with a canvas-based renderer. Bespin was way faster than other browser-based code editors at the time. Then the Ajax.org/Cloud9 folks came along with their Ace editor[2], which was DOM-based and still very fast. We ended up merging the projects. edit to add: and switching to D…
> ... it's hard to beat just drawing on a canvas or using WebGL. Both of these APIs perform quite poorly for what they're doing. To compete with native, the web platform needs simple low-level APIs that do not have a lot of Javascript marshalling overhead and other performance cliffs. You can always build a more convenient library above low-level interfaces, but the opposite is not true.
When it comes to Canvas, do you mean that it actually performs poorly when putting pixels on the screen using putImageData, or do you mean that it does that fine but it performs poorly when it comes to drawing vector graphics? In either case, do you know why it performs poorly?
Personally, I would be happy if Canvas just let you put raw pixel data on the screen and did that as well as possible. I have never felt any need for its vector graphics features. To me, they seem too high-level for what Canvas is supposed to be. But I guess things are different when it comes to using the graphics card, since from what I understand it is actually optimized for drawing polygons.