Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Google Docs will now use canvas based rendering

workspaceupdates.googleblog.com

Post reply on HN
Print view View original

301–310 of 953 posts

Re: Google Docs will now use canvas based rendering

#301

Post by worldsayshi »

k__ wrote: post #240
kyrra wrote: post #86

(googler, opinions are my own. I know nothing about this project). I really hope this fixes the large-document problem. As someone that has to deal with large specs (1000+ page MS Word documents), Google Docs does a not-so-great job of handling them. I also understand this is why many writers don't like Google Docs to write the entire book in, as things start slowing down when you get into the hundreds-of-pages. I do…

I hope so too. But I once read, most performance problems come from all the changes that are chached for a document and yoh can fix the problem by copying the text of an old document in a new one. This doesn't let me hope for huge performance gains.

Yeah cached changes shouldn't have anything to do with dom performance.

Re: Google Docs will now use canvas based rendering

#302

Post by maple3142 »

chalcolithic wrote: post #95
est31 wrote: post #80

Earlier quoted context omitted.

It depends on what you do with it. HN is extremely fast.

(Un)folding a 100+ comment subtree is kind of slow, don't you think?

Same experience on my Android phone. I just tried to unfold 75 comment, it has a noticeable latency in both chrome and firefox.

Re: Google Docs will now use canvas based rendering

#303

Post by mihcsab »

stefan_ wrote: post #237
pdkl95 wrote: post #99

Ever since WebAssembly was first introduced, I thought it was obvious[1][2] that the end game for those that want to control the web is sending opaque binary blobs of code that only use the browser for the canvas tag's framebuffer. Font rendering and layout can all easily be accomplished by embedding libraries like freetype. This breaks all forms of user control - like ad blockers - and turns the web back into cable…

This is what Flutter on the web is, by the way. You can try it out here: https://gallery.flutter.dev/#/ and marvel at the impossible to select text, one of the many affordances violently excised here. If it wasn't still incredibly slow even on a cutting-edge Zen3, Nvidia 3070 system they might almost be on to something here.

It`s not slow on an old intel i3 laptop and on a motorola one phone. I keep seeing these comments about flutter web with different examples, they are never slow on my old devices. Also you can make the text selectable if you want to.

Re: Google Docs will now use canvas based rendering

#305

Post by ehnto »

stefan_ wrote: post #237
pdkl95 wrote: post #99

Ever since WebAssembly was first introduced, I thought it was obvious[1][2] that the end game for those that want to control the web is sending opaque binary blobs of code that only use the browser for the canvas tag's framebuffer. Font rendering and layout can all easily be accomplished by embedding libraries like freetype. This breaks all forms of user control - like ad blockers - and turns the web back into cable…

This is what Flutter on the web is, by the way. You can try it out here: https://gallery.flutter.dev/#/ and marvel at the impossible to select text, one of the many affordances violently excised here. If it wasn't still incredibly slow even on a cutting-edge Zen3, Nvidia 3070 system they might almost be on to something here.

Unselectable text, and links that are actually javascript so you can't preview them, or open them in new tabs.

But who are we kidding, the web is javascript all the way down now.

Re: Google Docs will now use canvas based rendering

#306

Post by intrasight »

mekkkkkk wrote: post #152
sgt wrote: post #117

Earlier quoted context omitted.

I am also wondering about this. Having recently built a production app in Flutter Web used by millions of people, I am very eager to hear about other people's experiences with Flutter Web in real life applications.

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

#307

Post by clon »

stefan_ wrote: post #237
pdkl95 wrote: post #99

Ever since WebAssembly was first introduced, I thought it was obvious[1][2] that the end game for those that want to control the web is sending opaque binary blobs of code that only use the browser for the canvas tag's framebuffer. Font rendering and layout can all easily be accomplished by embedding libraries like freetype. This breaks all forms of user control - like ad blockers - and turns the web back into cable…

This is what Flutter on the web is, by the way. You can try it out here: https://gallery.flutter.dev/#/ and marvel at the impossible to select text, one of the many affordances violently excised here. If it wasn't still incredibly slow even on a cutting-edge Zen3, Nvidia 3070 system they might almost be on to something here.

It refreshes dormant memories of what Flash used to feel like.

For me the balance is still the same. Fine for highly interactive things such as games. For everything else, ugh...

Re: Google Docs will now use canvas based rendering

#308

Post by Tyriar »

I wrote the terminal canvas renderers in VS Code that has been called out a few times here. Initially I implemented a canvas renderer using just a 2d context to draw many textures which sped things up "5 to 45 times"[1] over the older DOM renderer.

Since then I moved onto a WebGL renderer[2] which was mostly a personal project, it's basically the first canvas renderer but better in every way since it works by organizing a typed array (very fast) and sending it to the GPU in one go, as opposed to piece meal and having the browser do its best to optimize/reduce calls. This was measured to improve performance by up to 900% in some cases over the canvas renderer, but actually much more than that if for example the browser has GPU rendering disabled and tried to user the canvas renderer on the CPU.

My opinion here is that canvas is a great technology, capable of speeding things up significantly and getting close to native app performance. It comes with very real trade offs though:

- Cost of implementation and maintenance is much higher with canvas. This is particularly the case with WebGL, there have been very few contributions to xterm.js (the terminal frontend component) in the WebGL renderer because of the knowledge required. - Accessibility needs to be implemented from scratch using a parallel DOM structure that only gets exposed to the screen reader. Supporting screen readers will probably also negate the benefits of using canvas to begin with since you need to maintain the DOM structure anyway (the Accessibility Object Model DOM API should help here). - Plugins/extensibility for webapps are still very possible but requires extra thinking and explicit APIs. For xterm.js we're hoping to allow decorating cells in the terminal by giving embedders DOM elements that are managed/positioned by the library[3].

More recently I built an extension for VS Code called Luna Paint[4] which is an image editor built on WebGL, taking the lessons I learned from working on the terminal canvas renderer to make a surprisingly capable image editor embedded in a VS Code webview.

[1]: https://code.visualstudio.com/blogs/2017/10/03/terminal-rend...

[2]: https://code.visualstudio.com/updates/v1_55#_webgl-renderer-...

[3]: https://github.com/xtermjs/xterm.js/issues/1852

[4]: https://marketplace.visualstudio.com/items?itemName=Tyriar.l...

Re: Google Docs will now use canvas based rendering

#309

Post by Andrew_nenakhov »

vishnumohandas wrote: post #243
lewisjoe wrote: post #30

We are working on a full-featured Google Docs alternative - https://writer.zoho.com . We are already capitalizing canvas technology for rendering documents across devices, except for the Web which still is DOM. Having a single codebase that renders across all platforms is our long-term motive, and it does require rendering to a cross-platform canvas backend - like Skia. I'm assuming Google Docs is already on that dir…

Are there plans to launch an end-to-end encrypted version of Writer?

We develop app that does have end-to-end encryption. From my experience, people who demand it rarely understand what it means and how many inconveniences true e2ee introduces to a product.

Anyway, if you are seriously worrying about the privacy of your documents, just use a localy deployed libreoffice and send encrypted files to your contacts.

Re: Google Docs will now use canvas based rendering

#310

Post by ehnto »

mihcsab wrote: post #303
stefan_ wrote: post #237

Earlier quoted context omitted.

This is what Flutter on the web is, by the way. You can try it out here: https://gallery.flutter.dev/#/ and marvel at the impossible to select text, one of the many affordances violently excised here. If it wasn't still incredibly slow even on a cutting-edge Zen3, Nvidia 3070 system they might almost be on to something here.

It`s not slow on an old intel i3 laptop and on a motorola one phone. I keep seeing these comments about flutter web with different examples, they are never slow on my old devices. Also you can make the text selectable if you want to.

Which is itself a commentary on the immaturity of the technology. I certainly wouldn't run it in production if I can't trust that all devices of a certain performance level can run it. Random performance issues on top-tier hardware is going to be a non-starter.
Post reply on HN