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

671–680 of 953 posts

Re: Google Docs will now use canvas based rendering

#671

Post by jakemal »

notyourwork wrote: post #3

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…

It is not unreasonable to request that devs building on top of your platform use an API. They also aren't requiring it, they are simply suggesting it to avoid future breakages when they change the internals of how their application works.

Requiring that they maintain this compatibility would be like requiring the maintainer of an OS library to maintain the contract of a private method because my app relies on grepping their code base to parse the contents of the method.

When you don't have a defined set of public interactions with your app, every change is a breaking change.

Re: Google Docs will now use canvas based rendering

#673

Post by nonbirithm »

sp332 wrote: post #549
axiosgunnar wrote: post #527

Earlier quoted context omitted.

How will it work, if they are sending binary WASM blobs? This is akin to saying "pi hole can block ads in .exe files"

The question is, who is sending binary WASM blobs? That ad data needs to come from an ad server, and if network requests to the ad servers are blocked, the ads will not load.

> That ad data needs to come from an ad server

It might, but it doesn't have to be served from a different website. YouTube content is indistinguishable from ads since Google serves them both from the same domain. pi-hole does not work with YouTube ads, and it hasn't for years.

Needing to reverse engineer and recompile the YouTube app is the only way to block YouTube ads with the mobile client. It's the same situation with everything being a JavaScript canvas with custom rendering. The bar for preventing ad-infested content from being shown becomes much higher than simply removing an HTML element when everything is byte-compiled.

I feel like this is not talked about enough, because the implications are heartbreaking. This will be the end game for web ads: WASM + single canvas for ads and content + companies with the infrastructure to host ads on the same domain as the content. There will be no longer be a single content blocker that will be automatically compatible with a large ratio of web content if such a combination of tech becomes widely adopted. YouTube Vanced is essentially one of those specialized content blockers, where YouTube is a service lucrative enough to wall off with its own specialized ads implementation.

As mentioned earlier in this thread, I would guess that the only reason the ad agencies haven't won out and pushed WASM/canvas rendering everywhere is because of the necessity of screen readers.

Re: Google Docs will now use canvas based rendering

#674

Post by ctoth »

jasim wrote: post #594
hctaw wrote: post #553

Earlier quoted context omitted.

Efficient 3 dimensional position or range queries (line/column/page) is a pretty well studied problem. You don't need to query every point of the space to answer anything.

I could not find clear references with an initial search. Can you expand a bit more about this approach? Thanks.

I've used a segment tree[0] for a similar problem before. For 3D queries an R-tree may be more appropriate.

[0]: https://en.wikipedia.org/wiki/Segment_tree

Re: Google Docs will now use canvas based rendering

#675

Post by lol768 »

davb wrote: post #661
attilakun wrote: post #27

Earlier quoted context omitted.

I'm not sure but what you are suggesting is not outside the realm of possibility. There are already projects like https://makepad.dev/ which implement their GUI on top of WebGL. (Which is arguably more challenging than implementation on top of Canvas 2D.)

I expected scrolling to feel janky and "non-native" but it was fine. Text rendering, on the other hand... it was a bit of a blurry mess, compared to Chrome's native rendering (on Ubuntu 21.04).

Ctrl+scrollwheel for zoom also doesn't work; this seems awful for accessibility.

Re: Google Docs will now use canvas based rendering

#677

Post by Slartie »

josephg wrote: post #157
larodi wrote: post #77

Earlier quoted context omitted.

It was indeed a very strong marketing move for... decades to convince people, like smart people, that document editing can be a web-based thing. Actually, now that the browser is so ubiquitous that GUIs sit on top of it (think Electron), then is time to ask the very obvious question - since everyone seems to agree that universal GUI is needed (proof: the browser) then is the browser the right universal GUI? Not being…

> 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 think you have just described in broad strokes what will happen in the next decade of GUI development.

Re: Google Docs will now use canvas based rendering

#678

Post by jd3 »

jd3 wrote: post #669
dangoor wrote: post #563

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…

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 Preferences" button — the DOM update feels incredibly sluggish whereas both searching and sorting columns in the old xul tree always felt snappy and instantaneous

https://imgur.com/a/abhYoW8

Re: Google Docs will now use canvas based rendering

#679

Post by pictur »

dang wrote: post #550
pictur wrote: post #304

Earlier quoted context omitted.

I don't understand why stupid people downvote my comment. I just posted a link. Why are you so dumb?

Your link was fine, and has since been upvoted (see https://hn.algolia.com/?dateRange=all&page=0&prefix=true&sor... ), but a comment like this one breaks the site guidelines. Would you mind reviewing them? https://news.ycombinator.com/newsguidelines.html Edit: could you please stop posting unsubstantive comments generally? Your account has been doing a lot of that, and we're hoping for a little higher quality of disc…

I was going to write at length how bad a moderator you are, but I don't think you are capable of understanding it. I just feel sorry for you. You can be a better moderator. this is not your potential. let's delete my account and relax.

Re: Google Docs will now use canvas based rendering

#680

Post by snewman »

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 native-app word processing engines, here are some thoughts.

Word processors have extremely specific requirements for layout, rendering, and incremental updates. I'll name just two examples. First, to highlight a text selection in mixed left-to-right / right-to-left text, it's necessary to obtain extremely specific information regarding text layout; information that the DOM may not be set up to provide. Second, to smoothly update as the user is typing text, it's often desirable to "cheat" the reflow process and focus on updating just the line of text containing the insertion point. (Obviously browser engines support text selections, but they probably don't expose the underlying primitives the way a word processor would need. Similarly, they support incremental layout + rendering, but probably not specifically optimized in the precise way a word processor would need.)

Modern browser engines are amazing feats of engineering, but the feature set they provide, while enormous, is unlikely to exactly match the exacting requirements of a WYSIWYG word processor. As soon as your requirements differ even slightly from the feature set provided, you start tipping over into complex workarounds which impact performance and are hell on developer productivity and application stability / compatibility.

This is loosely analogous to CISC vs. RISC: browsers are amazing "CISCy" engines but if your use case doesn't precisely fit the expectations of the instruction set designer then you're better off with something lower-level, like Canvas and WASM. (I don't know whether Docs uses WASM but it would seem like a good fit for this Canvas project.)

Frameworks in general suffer from this problem. If you've ever had to fight with an app framework, or orchestration framework, or whatever sort of framework to accomplish something 5% outside of what the framework is set up to support, then you understand the concept.

Also, as noted in many comments here, browser engines have to solve a much more general problem than Docs, and thus have extra overhead.

Post reply on HN