Live data from Hacker News

Google Docs will now use canvas based rendering

workspaceupdates.googleblog.com

661–670 of 953 posts

Re: Google Docs will now use canvas based rendering

#661

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.)

I expected scrolling to feel janky and "non-native" but it was fine. Text rendering, on the other hand... it was a bit of a blurry mess, compared to Chrome's native rendering (on Ubuntu 21.04).

Re: Google Docs will now use canvas based rendering

#662

My 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?

They probably reimplement entirely from scratch by getting the position of the mouse and listening to click events.

Re: Google Docs will now use canvas based rendering

#663
post #485

Earlier 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.

> 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.

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

#664

Earlier 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…

They aren't that optimized, this small team changed Chromium's DOM to have better cache utilization and more coherent access patterns with data-oriented/SoA and got 6X speedup in some animation use cases:

https://meetingcpp.com/mcpp/slides/2018/Data-oriented%20desi...

Re: Google Docs will now use canvas based rendering

#666
post #227

Earlier 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?

About 2.1M, and it comes down to 624K gzipped which I feel is pretty acceptable. The whole app is about 6000 lines of dart.

Re: Google Docs will now use canvas based rendering

#667
post #550
post #304

Earlier 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…

You can delete my account. I do not want to be on this site any longer. There can be no quality in an environment with moderators like you.

Re: Google Docs will now use canvas based rendering

#668

Earlier 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.

I mean, yeah. But rolling it out to millions of users wouldn't really pass as dogfooding, though?

Re: Google Docs will now use canvas based rendering

#669

In 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 funny — Google's approach here reminds me of the Netscape/Mozilla XUL tree[0] element.

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

[4]: https://www.thunderbird.net/

[5]: https://www.seamonkey-project.org/

Re: Google Docs will now use canvas based rendering

#670

In 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.

>Both of these APIs perform quite poorly for what they're doing.

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.

Post reply on HN