Live data from Hacker News

Google Docs will now use canvas based rendering

workspaceupdates.googleblog.com

701–710 of 953 posts

Re: Google Docs will now use canvas based rendering

#701
post #678
post #669

Earlier quoted context omitted.

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

tangential but amusing — the old chrome://global/content/config.{xul/xhtml} used a XUL tree and rendered 0 DOM nodes to display its treechildren whereas the new about:config renders upwards of 4500 DOM nodes by default ignoring the fact that you can no longer sort by specific columns (name, status, type, value, etc), you can really feel how slow the new implementation is if you click the "Show Only Modified Preferenc…

Yeah it's a real shame it's all moving to HTML/JS for the chrome & e.g. devtools, even if it's more "maintainable".

Re: Google Docs will now use canvas based rendering

#702
post #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 a…

Why can't XUL vs DOM just be the same data with a fast C++ API and a slow JS API?

Re: Google Docs will now use canvas based rendering

#703

Earlier quoted context omitted.

Man, this is a very dramatic interpretation of their intent. Docs doesn't even have ads. They actually do have issues rendering consistently across browsers (I ran into this just like 2 days ago where something that had been carefully laid out on Chrome looked different in Safari). My bigger criticism of this is that I imagine it was a very large refactor at a time when docs has barely evolved for years and still rem…

Ahh yes because Google, an ad company, will never implement this where they do have ads.

I never said they would never do this. I just said it was over dramatic and making big assumptions that this action by google was part of some nefarious plot to turn the internet back into corporate tv, especially given that there are very good reasons in this case to make this change without those assumptions.

Re: Google Docs will now use canvas based rendering

#704
post #683

Speaking as one of the original three authors of Google Docs (Writely), but zero involvement in this project (I left Google in 2010): I'm seeing a lot of comments asking how JavaScript-on-Canvas could possibly outperform the highly optimized native code built into the browser engines. It's been a long time since I've really been involved in browser coding, but having written both Writely and, farther back, several na…

How would you recommend someone to get started learning about the architecture of Text editors / word processors? I think Monaco from vscode is probably an interesting read but I’ve never looked at such a big open source code base before. Is there something you can recommend to understand better how it works architecturally?

I recommend reading about the internals of CodeMirror and ProseMirror: e.g. https://codemirror.net/1/story.html.

Re: Google Docs will now use canvas based rendering

#705

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.

Meaning they're creating text dynamically with the click event? I'd assume that'd be chicken-and-egg where the browser wouldn't respond to the click event if there's no text to select?

Re: Google Docs will now use canvas based rendering

#706
post #701
post #678

Earlier quoted context omitted.

tangential but amusing — the old chrome://global/content/config.{xul/xhtml} used a XUL tree and rendered 0 DOM nodes to display its treechildren whereas the new about:config renders upwards of 4500 DOM nodes by default ignoring the fact that you can no longer sort by specific columns (name, status, type, value, etc), you can really feel how slow the new implementation is if you click the "Show Only Modified Preferenc…

Yeah it's a real shame it's all moving to HTML/JS for the chrome & e.g. devtools, even if it's more "maintainable".

I use the modern Firefox HTML5/JS dev tools on a daily basis and love the featureset that they provide, though it is equally shocking to compare the feel to that of the old DOM Inspector[0] (and Venkman[1], the old JS debugger), which was a XUL add-on for DOM inspection that used to run in Firefox, Thunderbird, and SeaMonkey.

What feels snappy and instantaneous in DOM Inspector feels somewhat muddy and laggy in the modern devtools.

While I greatly appreciate the amount of features that Mozilla has integrated into the modern (post-firebug) devtools over the years, it is a little sad that the next generation will never get to experience just how fast some narrow aspects of web development used to be.

https://imgur.com/a/JZoSTXf

[0]: https://addons.thunderbird.net/en-us/firefox/addon/dom-inspe...

[1]: https://addons.thunderbird.net/en-us/firefox/addon/javascrip...

Re: Google Docs will now use canvas based rendering

#707
post #630
post #582

Earlier quoted context omitted.

Can someone explain why https://makepad.dev/ is extremely slow and "unusable" on Microsoft Edge browser but run smoothly on Chrome? Is it because of bad WebGL perf on JavasSript perf in general?

For me, it's not very fast in chrome.

Can you give a bit more flavor to "not very fast"? I'm on a measly chromebook and scrolling, selecting text, expanding directories, everything is smooth and high framerate.

Is there a specific operation that is not fast? Opening it for the first time took a few seconds but afterwards it was pretty buttery.

Re: Google Docs will now use canvas based rendering

#708

I don't build extensions or work on much front end web lately but this reads like Google wants more control over their stuff. The web is becoming less open. > By moving away from HTML-based rendering to a canvas-based rendering, some Chrome extensions may not function as intended on docs.google.com and may need to be updated. > If you are building your own integrations with Google Docs, we recommend using Google Work…

Did you feel the same when Maps went from HTML to Canvas?

There is no factual basis for your claims. The simplest and most obvious answer is performance. Docs these days can take 5-10s to fully open, especially with comments and annotations.

Re: Google Docs will now use canvas based rendering

#709
post #683

Speaking as one of the original three authors of Google Docs (Writely), but zero involvement in this project (I left Google in 2010): I'm seeing a lot of comments asking how JavaScript-on-Canvas could possibly outperform the highly optimized native code built into the browser engines. It's been a long time since I've really been involved in browser coding, but having written both Writely and, farther back, several na…

How would you recommend someone to get started learning about the architecture of Text editors / word processors? I think Monaco from vscode is probably an interesting read but I’ve never looked at such a big open source code base before. Is there something you can recommend to understand better how it works architecturally?

Here’s a blog post detailing some vscode internals: https://code.visualstudio.com/blogs/2018/03/23/text-buffer-r...
Post reply on HN