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

781–790 of 953 posts

Re: Google Docs will now use canvas based rendering

#781

Post by pshc »

felixfbecker wrote: post #746
delroth wrote: post #397

Earlier quoted context omitted.

"Displaying documents" and "displaying editable documents" are two completely different beasts. The web browser has never dealt well with displaying editable documents, the closest standard that exists is contentEditable and pretty much everyone agrees that it sucks and is not fit for complex use cases.

Why can't Google work on improving `contenteditable`? It would benefit so many and the problems are well-known. It's probably even used by Google somewhere

You could easily burn five years trying to fix `contenteditable` and get nowhere. There's too much legacy and impedance mismatch. Better to start fresh at this point.

Re: Google Docs will now use canvas based rendering

#782

Post by alvarob »

I think the trend of rendering web apps in canvas is about to explode and it will be ironically promoted by one of the biggest defenders of HTML: Google. The reason I believe is that they no longer need to parse web apps using the DOM because instead they are/will be using Machine Vision.

Re: Google Docs will now use canvas based rendering

#783

Post by erlich »

felixfbecker wrote: post #746
delroth wrote: post #397

Earlier quoted context omitted.

"Displaying documents" and "displaying editable documents" are two completely different beasts. The web browser has never dealt well with displaying editable documents, the closest standard that exists is contentEditable and pretty much everyone agrees that it sucks and is not fit for complex use cases.

Why can't Google work on improving `contenteditable`? It would benefit so many and the problems are well-known. It's probably even used by Google somewhere

Good point. Imagine the millions of collective hours that would have been saved by everyone hacking their own text editors together.

Re: Google Docs will now use canvas based rendering

#784

Post by MarkSweep »

jd3 wrote: post #744
pcwalton wrote: post #719

Earlier quoted context omitted.

> 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. XUL is a maintenance burden and exacts a development tax on new features (having to make the Servo CSS engine support XUL so that i…

Thanks for the reply! I'm a big fan of your work. I can only imagine the nightmare of trying to implement two separate XUL HTML/CSS flex/box models in Servo/Rust. For readers that are unaware, there is also a great blog post breaking down some of these points in finer detail [0][1]. I guess my question is — are there replacements planned for any of the legacy yet performant XPCOM interfaces / XUL elements like nsITre…

I'm not a XUL or JavaScript expert, but there is evidence that you can implement a virtualized list in regular HTML:

https://react-window.vercel.app/

Re: Google Docs will now use canvas based rendering

#785

Post by [deleted] »

brabel wrote: post #717
mumblemumble wrote: post #607

Earlier quoted context omitted.

The thing is, when you're shopping for GUI toolkits, "try it and find out" isn't a great decisionmaking rubric. Partially because there are a zillion of them and you simply can't try them all, and partially because learning one is expensive and time-consuming, so, unless you genuinely enjoy that kind of thing, you kind of want to pick one in one shot. Meaning that, in a slate of options where one of them can definite…

Flutter is not competing with general GUI toolkits, it's competing with fully crossplatform toolkits, of which there's only a couple of real contenders for real-world apps: React Native and maybe Sciter. Nothing else is production-ready and can run on the web, iOS, Android and desktop OSs (Linux, Windows, MacOS). It's not competing with pure web frameworks. For this reason, yes, I think that if you're going to critic…

[deleted]

Re: Google Docs will now use canvas based rendering

#786

Post by azinman2 »

progval wrote: post #774
azinman2 wrote: post #768

Earlier quoted context omitted.

But that's not happening, as I'm able to select text on iOS Safari and have it give me the copy/paste options above it. If the text wasn't available, it would also completely break any kind of screen reader / accessibility feature so something has to be supporting this at a native-browser level.

I don't know about iOS, but on Firefox Desktop, the right-click menu is emulated by the canvas, and it uses the clipboard API to copy it. > If the text wasn't available, it would also completely break any kind of screen reader / accessibility feature so something has to be supporting this at a native-browser level. When using a screen reader, it tells you you press Ctrl+Alt+Z, which loads an iframe containing (only?!…

It looks like on Safari on macOS they also hijack right-click menu, but text selection works such that I can go to Edit>Copy and it works.

What tells you to press Ctrl+Alt+Z? That's not a great experience for you to interactively edit a document if you have accessibility needs.

Re: Google Docs will now use canvas based rendering

#787

Post by manx »

nine_k wrote: post #241

The Web started as a document display and delivery framework. Now it has turned into an application delivery framework, which uses the old document-rendering abilities to display the UI, with many quirks and workarounds, because DOM was never intended as a performant dynamic medium. With canvas and WebGL taking more and more, it will turn back into an X terminal, with more advanced network capabilities. If most impor…

I'm wondering if at some point it makes sense to compile servo to webassembly and let it render to a canvas.

Producing a good user experience with pure canvas rendering is a lot of work. A tree stucture to manage UI elements makes this easier. Flutter is going in a similar direction here.

The interesting thing would be that the engine wouldn't need to conform to web standards anymore, while providing a guaranteed consistent cross browser experience. One could probably strip away lots of old dom concepts that make the dom slow today.

Re: Google Docs will now use canvas based rendering

#788

Post by jd3 »

MarkSweep wrote: post #784
jd3 wrote: post #744

Earlier quoted context omitted.

Thanks for the reply! I'm a big fan of your work. I can only imagine the nightmare of trying to implement two separate XUL HTML/CSS flex/box models in Servo/Rust. For readers that are unaware, there is also a great blog post breaking down some of these points in finer detail [0][1]. I guess my question is — are there replacements planned for any of the legacy yet performant XPCOM interfaces / XUL elements like nsITre…

I'm not a XUL or JavaScript expert, but there is evidence that you can implement a virtualized list in regular HTML: https://react-window.vercel.app/

I recently wrote a somewhat performant react-virtualized[0] list for a project at work, though it's definitely a bit trickier in plain HTML/JS.

As far as the XUL virtualized tree goes, a couple of Mozilla engineers wrote some examples using plain html/javascript + DOM node manipulation[1]. While promising, I can't imagine that this implementation could ever be as fast as the compiled C++ one[2].

[0]: https://github.com/bvaughn/react-virtualized

[1]: http://benbucksch.github.io/trex/fastlist-test.html

[2]: https://searchfox.org/mozilla-central/source/layout/xul/tree...

https://news.ycombinator.com/item?id=14158170

Re: Google Docs will now use canvas based rendering

#789

Post by kannanvijayan »

snewman wrote: post #736
kannanvijayan wrote: post #724

Earlier quoted context omitted.

I'd like to chime in here as someone who has worked on optimizing the execution of your code :) Google docs specifically was one of the subjects of a particular performance push when I was working on Spidermnonkey within Firefox, and I got to see how it behaves under the hood pretty well. The thing that stands out to me the most was the giant sparse array (a regular js-native array) being used to store layout informa…

This is why I love HN. :-) However, I can't claim credit (or blame, but I would argue mostly credit) for that code. There have been three generations of the Docs editor that I know of: 1. The original, which I was involved in, was an unholy mess perched shakily atop contenteditable. As such, it contained no layout or rendering code (but did all sorts of horrid things under the hood to massage the HTML created by the…

You're right. This was a few years ago, so well after 2010.

And yes, I'd say credit as well for the layout code, not blame. I wasn't knocking the code - for that era sparse arrays + DOM stuff were pretty common approaches and there didn't exist better web tooling than that.

It's only been the last few years I'd say where the optimization quality (on the engine side) and API support has been good enough to justify this sort of approach ofjust plumbing your own graphics pipeline on top of the web.

That was a spidermonkey issue. I treat that experience more as a lesson in how obscure corner cases left as perf cliffs never stay obscure corner cases, and always get exercised, and you can't afford to ignore them for too long.

Re: Google Docs will now use canvas based rendering

#790

Post by josephg »

PoignardAzur wrote: post #647
josephg wrote: post #157

Earlier quoted context omitted.

> then is the browser the right universal GUI? Absolutely not; but the web has became the behemoth it is through an absurd amount of money and engineering work. Chrome (well, Chromium) has 34 million lines of code now[1]. If we assume any competing universal GUI platform will need a similar amount of engineering effort, there's a very small list of companies in the world who have the resources to fund an effort like…

I really like that scenario, but I don't think market forces are moving towards it. Then again, we got wasm, and that feels like a miracle in itself.

Well, it’s clearly what the Google docs team wants. And it would yield higher performance for other similarly complex web apps (eg Figma). And allow native UI development in more languages (Blazor). It also looks to be the sort of thing the Flutter team want for web builds. And it could work well for the base system of chromeOS too.

For whatever reason, Google invests hundreds of millions each year into chrome, and trusts their engineers’ leadership on how to make it succeed. The question in my mind is if browser engineers themselves decide to push in this direction.

Post reply on HN