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

811–820 of 953 posts

Re: Google Docs will now use canvas based rendering

#811

Post by philosopher1234 »

yashap wrote: post #808

For everyone saying "Google is pushing canvas usage to kill ad-blocker effectiveness", maybe, but most of Google's ad revenue already works around ad blockers. Most of their ad revenue comes not from their display network (ads that they serve on other ppl's property), but from showing ads on their own properties. Only ~13% of their revenue comes from ads displayed on properties they don't own: https://finshots.in/inf…

That 3% you're referring to is 5.5 billion dollars, which easily justifies canvas usage. I don't personally see the connection between google docs and ads, but I think this analysis is misleading.

Re: Google Docs will now use canvas based rendering

#812

Post by bscphil »

jd3 wrote: post #678
jd3 wrote: 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…

Similarly, my understanding is that the TreeStyleTab extension was forced to migrate in the same manner and it can get very sluggish as well when you have a lot of tabs open.

Re: Google Docs will now use canvas based rendering

#813

Post by devongovett »

lhnz wrote: post #800
devongovett wrote: post #793

This is very bad for accessibility. Rendering things in canvas means there is no DOM, which means nothing for screen readers to read. To be fair, the old google docs editor was also very bad for a11y, but at least there was potential to improve it. This removes that option. They could have worked with the Chrome team to help improve standards for everyone, but decided to reimplement the rendering engine from scratch…

The example that Google shows in their post has accessibility features [0], although currently these need to be switched on with a keyboard shortcut (⌘+Option+Z). Pay attention to `document.getElementById('docs-aria-speakable')`. [0] https://docs.google.com/document/d/1N1XaAI4ZlCUHNWJBXJUBFjxS...

Yeah it's pretty bad to have accessibility be a mode though. Also, since it's completely non-standard, the usual screen reader navigation keys don't work as expected and users have to learn a completely custom interface. Better than nothing but it's not great.

Re: Google Docs will now use canvas based rendering

#814

Post by esrauch »

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

I've heard there was actually a vocal push from Chrome for Docs to use contenteditable and even with motivated Chrome engineers they couldn't make it competitive. They basically could never fix it for Safari.

Re: Google Docs will now use canvas based rendering

#815

Post by rossjudson »

sanxiyn wrote: post #798
aloer wrote: post #683

Earlier quoted context omitted.

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?

There is no substitute to building one yourself, but The Craft of Text Editing book has a lot of accumulated wisdom. It is Emacs-centric, but basics are same. http://www.finseth.com/craft/

One of my first programming projects as a teenager back in terminal-type days was to write my own text editor for the Atari ST. I was super happy with it, and sold three (3) copies of it! That made me very happy at the time.

Of course there was that time that I messed with the save/load code and destroyed the text files of one of my customers. Not so happy with that! Saved it by writing a fix system, and that actually led to being hired at that guy's company for my first "real" job. ;)

Re: Google Docs will now use canvas based rendering

#816

Post by oh_sigh »

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

Ok, and then the new version is only supported by chrome. So they still need to keep their old rendering engine up to date. Will the other big browsers ever go along with supporting it? Or will that work be lamented as google trying to own the web and just updating standards that benefit their bottom line?

Re: Google Docs will now use canvas based rendering

#817

Post by cromwellian »

kannanvijayan wrote: post #724
snewman wrote: post #680

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…

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…

The sparse array is likely to be a protobuf. I ran into this issue with Firefox when working on Google Inbox, it was one of the reasons why the Firefox version was delayed, but there was degenerate performance with sparse arrays. (I'll note, various conspiracy theories on HN thought it was a deliberate attempt to hamper FF, when in reality, is was an unintended consequence of usage of an old protobuf format which never caused a problem until protobufs with huge extension fields were used in a specific way in the codebase, so the problem was discovered late)

protobufs can be stored in array format. In that format, each field number is basically it's index in the array. Extension fields in protobufs typically grab high numbered slots. So if you have a prototype with 1 field (id = 1), and one extension field (e.g. id = 10000000), you now have an array with [undefined, stuff, ... 999999 ..., stuff] and various array operators seem to reify this into a real array in older versions.

Re: Google Docs will now use canvas based rendering

#818

Post by smithza »

Tyriar wrote: post #308

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

Okay, if anyone else after reading Accessibility needs to be implemented from scratch felt ashamed, raise your hands with me. SW engineers suffer from assuming everyone is like them and there are no corner cases. My Mom was recently sued for violating ADA with her real estate website not working with screen readers well enough.

Re: Google Docs will now use canvas based rendering

#820

Post by rossjudson »

snewman wrote: post #810
Graffur wrote: post #792

Earlier quoted context omitted.

Out of curiosity, what have you moved on to now that you don't do browser coding?

After leaving Google I founded scalyr.com. To get an idea of the type of work we're doing, this old blog post holds up: https://www.scalyr.com/blog/searching-1tb-sec-systems-engine... .

Kids these days usually don't understand exactly how fast hardware actually is. ;)

"I have 200 million entries in a table I need to compress. I'm gonna write a flume job! I estimate it will take 5 minutes to start the job and a half hour to run! Then I'll spend a few days figuring out how to shard it so it actually finishes."

"Sounds good. But I also have this bit of Java code here that does the same compression on my desktop in about 30 seconds. Would you like that instead? You could convert it to C++ if that would make you feel better."

yellowbrick.com did some neat stuff pushing the query algebra down into the flash storage firmware.

Post reply on HN