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

801–810 of 953 posts

Re: Google Docs will now use canvas based rendering

#801

Post by m0dest »

woah wrote: post #199
shadowgovt wrote: post #149

Earlier quoted context omitted.

> Kind of surprised I'd assume a significant cost-benefit tradeoff. For all its flaws, the DOM rendering algorithm is at least "document-like," so there's a lot of wheel-reinventing to do going from just using the DOM to a custom document layout implementation underpinning a canvas-targeted rendering algorithm.

Look at the Google docs generated html markup some time. It’s not making nice neat ’s and ’s.

How? I thought they blocked access to the native underlying document format. Or do you mean the HTML export?

Re: Google Docs will now use canvas based rendering

#802

Post by Dylan16807 »

vkou wrote: post #663
AlexandrB wrote: post #523

Earlier quoted context omitted.

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

Security patches aren't important for most software, when it's not connecting out to any servers.

Re: Google Docs will now use canvas based rendering

#803

Post by kizer »

I've been working on a canvas-mostly render library. Some things like text input would require using the native component to some degree; e.g., the input element could be invisible while the canvas would render the text field in its place.

Honestly, why even bother with the DOM? Even for "article" sites; you can have pixel perfect control over your rendering, especially if you even implement your own anti-aliased bezier curve rendering algorithms. There's already a library that processes fonts (opentype.js) and returns the parameters of the bezier curves that need to be drawn to construct the glyphs.

You're fine still using HTML/CSS for a bunch of reasons (lighter static sites, already have developed codebases for each).

But, why not own the whole thing in TS/JS? For web applications, you'd then have pixel perfect consistency across browsers and mobile devices. There are two ways Flutter, for example, compiles to a web application[0]: either to a mix of canvas, CSS, SVG, and HTML, or just to pure WebGL Canvas using a WASM build of Skia (that's right - the engine that renders HTML/CSS in the first place).

So with WebAssembly and the Canvas, especially taking into account the upcoming WebGPU API which will unlock even better render performance, I'd rather have my whole application be defined in JS/TS and own all of the experience down to the pixel -- complete control. Obviously this is assuming convenient libraries (in WASM/JS) for rendering text/curves/etc. to canvas will exist.

Would be awesome for certain web app usecases.

[0] https://flutter.dev/docs/development/tools/web-renderers

Re: Google Docs will now use canvas based rendering

#804

Post by perfunctory »

Strangely, this reminded me of Bret Victor

> To deliver her message most effectively, the visual designer needs as much control as possible over what the viewer sees. But, by definition, the designer only has direct control over the tool. She is at the mercy of whatever platform implementation the recipient happens to supply. This implies that a good platform must be as simple and as general as possible.

> From a practical (and historical) standpoint, we can assume that no complex specification will be implemented exactly. This, in itself, is not a problem. However, multiple, decentralized implementations of a complex specification will be incorrect in different ways. A platform consisting of the union of all possible implementations is thus arbitrarily unreliable—the designer can have no assurance of what a recipient actually receives. For a platform to be reliable, it must either have a single implementation, or be so utterly simple that it can be implemented uniformly. If we assume a practical need for open, freely implementable standards, the only option is simplicity.

Re: Google Docs will now use canvas based rendering

#805

Post by cxr »

jackcviers3 wrote: post #517
xxpor wrote: post #366

Earlier quoted context omitted.

I personally didn't even bother checking out VS code because it was based on electron, and so I figured the performance just wouldn't be there because it's doing all of this awkward web stuff while trying to be an IDE. I was completely wrong though. Using it, it really doesn't feel like a web app at all. It's really shocking and impressive. It feels like a text editor. Perhaps I should learn more about what they're d…

The major problem I have with electron apps is that they eat memory for breakfast, lunch, and dinner. This happens with jvm applications as well, but you can limit the max heap size and force the garbage collector to work more, trading off speed for the ability to run more apps side by side. AFAIK, you can't limit the memory used in electron apps, and they don't respond by sharing heap with their child processes. Wit…

The majority of the problems with "Electron" are actually just problems with the development style used by the types of people who publish and consume packages from NPM.

We've gone from a world where JS wasn't particularly fast, but it powered apps like Netscape, Firefox, and Thunderbird just fine (despite the fact that the machines of the era were nothing like what we have today) and most people didn't even know it, to a V8-era world where JS became crazy fast, to the world we're in now where people think that web-related tech is inherently slow, just because of how poorly most apps are implemented when they're written in JS.

If you want to write fast code, including for Electron, then the first step is to keep your wits as a programmer, and the second step is to ignore pretty much everything that anyone associated with NPM and contemporary Electron development is doing or that would lead you to think that you're supposed to be emulating.

Re: Google Docs will now use canvas based rendering

#806

Post by uranium »

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 sat by Steve when Writely joined Google. [Hi Steve!] I sat by the Google Page Creator team when they were a thing. Regardless of performance, it's a miracle that a WYSIWYG editor can be written on top of the DOM at all, let alone a performant one. They had to work multiple miracles a day just to get bulleted lists to work somewhat reliably.

I have no doubt whatsoever that a Canvas-based editor can be faster and easier to maintain. I don't know how well it'll handle accessibility issues, though. I expect they'll have to do a lot of tedious work to get screen readers and the like to be happy.

Re: Google Docs will now use canvas based rendering

#807

Post by DaiPlusPlus »

tshaddox wrote: post #745
DaiPlusPlus wrote: post #151

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…

The web is (or at least was) document-first, yes, but Google Docs is an extremely heavily-featured WYSIWYG word processing and desktop publishing application that happens to be distributed on the web (in addition to other platforms). The fact that you're (sometimes) using Google Docs to generate a simple document that could easily be represented with simple HTML does not imply that Google Docs itself is a natural can…

> My impression is that Google Docs never used contentEditable and instead wrote their own layout and editing engine that manually rendered out DOM, and they're now changing that to render out to canvas.

Back before Google owned Google Docs, it was a non-Google company and website called Writely, and their website was basically a document-hosting system tied to a fairly stock `contentEditable` editor.

This was around 2005 - back when every web-application development client would insist that users have WYSIWYG/rich-text editors - of course they had no idea how WYSIANLWYG (What you see is absolutely nothing like what you'll get) those WYSIWYG editors are like.

Re: Google Docs will now use canvas based rendering

#808

Post by yashap »

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/infographic/breaking-down-revenue-stream... And "only" ~25% of users use ad blockers, so ad blockers likely only hit Google's total revenue by ~3%.

Ad blockers mostly work by blocking known display-ad-serving JS scripts, that ppl include on their page. Ads within Google search, Gmail, YouTube (and big non-Google advertisers like Facebook, Twitter, Reddit), don't use this approach, the ads are much more built into the page (embedded in product JS bundles, or simply returned by the backend from Ajax calls, mingled in with non-ad data). These ads are really hard to block, regardless of whether the page is a traditional web document, or uses canvas. Blocking them basically involves parsing the page and looking for things you think are ads, which is incredibly difficult to make work reliably over time, so nobody really bothers, and that's true regardless of canvas vs. traditional web document.

Re: Google Docs will now use canvas based rendering

#809

Post by zxzax »

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 really doubt anyone is going to revive those old legacy widgets. That style of widget is flawed and predates MVC-style design, you'll find it becomes very impossible to present non-string data with that tree. Most applications now will want to show arbitrary widgets within the table, and for that they'll use the standard HTML/CSS. I would expect you can do something comparably fast by using a virtualized list in HTML, along with IndexedDB.

Re: Google Docs will now use canvas based rendering

#810

Post by snewman »

Graffur wrote: post #792
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…

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....
Post reply on HN