Live data from Hacker News

Google Docs will now use canvas based rendering

workspaceupdates.googleblog.com

711–720 of 953 posts

Re: Google Docs will now use canvas based rendering

#711
This is great news.

If you've tried using Google Docs extensively for layout-heavy things, you've probably noticed a bunch of subtle things break a little bit, for example as pixel rounding errors accumulate down a page. This can be especially evident when using things like lots of table cells, borders, and zoom levels different from 100%. The blinking cursor can sometimes be almost a full line misaligned from the text being edited.

Also if you've tried using Docs across different platforms and browsers, there can be subtle differences in line heights, word-wrapping, and so on. Which might not seem like a big deal, until you try to write your term paper to be no more than 25 pages long, and then when you go to a shared computer to print it, it's now 26 pages because a bunch of lines are now wrapping that weren't before, and your professor won't accept it!

If canvas means Google now has total control over precise element and letter positioning and wrapping, this will be a BIG step forwards in truly being a consistent, cross-platform, WYSIWYG word processor, as opposed to the way it's often been "usually mostly right but not always exactly".

Websites are supposed to be responsive and flexible and not depend on exact font rendering. But word processors really do need reliable control over layout when producing serious documents like papers, resumes, etc.

Re: Google Docs will now use canvas based rendering

#712

Earlier quoted context omitted.

> this reads like Google wants more control over their stuff. The web is becoming less open. Absolutely agreed. I'd also be surprised if they don't try to roll out the same for search results, ostensibly for the purpose of improving performance, but actually to thwart ad-blockers.

The only thing that's kept everyone from doing that, so far, is accessibility. If not for that all the major ad platform companies (FB, Twitter, Google, and so on) would be already be all-in on Canvas. Accessibility concerns make it both expensive to develop a UI that renders to canvas, and ensures that the content can be processed & understood by a program (else how will assistive tools read it?), which opens up the…

Do you have any evidence for this idea?

Re: Google Docs will now use canvas based rendering

#713

Earlier quoted context omitted.

We develop app that does have end-to-end encryption. From my experience, people who demand it rarely understand what it means and how many inconveniences true e2ee introduces to a product. Anyway, if you are seriously worrying about the privacy of your documents, just use a localy deployed libreoffice and send encrypted files to your contacts.

What app are you developing?

https://github.com/redsolution/xabber/ this one. Page is rather dated, though.

Re: Google Docs will now use canvas based rendering

#714

Earlier quoted context omitted.

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?

No, I mean they would draw the selection themselves on the canvas. And they would get the event simply because the user clicked on the canvas.

Re: Google Docs will now use canvas based rendering

#715
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 don't think there's any way better than build a text editor from scratch, you have to understand the exact problem before reading other people's solutions.

Re: Google Docs will now use canvas based rendering

#716
post #79

Earlier quoted context omitted.

I believe this 100%. After using google office for years (just because it's free and cloud-based), I recently tried MS Word and Excel recently at work. The different was mind-blowing. I forgot just how functional and straightforward MS Office is compared to the clunky, barebones google options. If I wanted a desktop-first, cloud-backed solution, what would be the most future-proof and durable? Can I use Open Office a…

> Can I use Open Office across OSes? I would recommend Libreoffice over Openoffice, but yes (for both) And you can of course backup to your cloud service of choice. The main benefit of google docs, o365, etc. Is real-time collaboration. But there is no reason why a desktop app couldn't support realtime collaboration with a suitable backend service.

The only time I've ever seen real-time Google Docs collaboration has been during meetings which should have been an email. Total waste of everyone's time. Not to mention the horrible UX of people constantly moving their cursor around and moving text around. I'd suggest that pass-the-baton style collaboration would be a much better UX if you absolutely must collaborate real-time on creating a document. Which I find the premise to be incredibly dubious to begin with.

Re: Google Docs will now use canvas based rendering

#717
post #525

Earlier quoted context omitted.

I said "claims to" because I don't know how I can verify if it is. The other person responding to me correctly mention how they suggest tools to scan for accessibility issues on iOS and Android, but they don't say how to do that on the web... have you managed to somehow figure out what is not currently working, exactly? Regarding performance: Chrome uses Skia to render the DOM, why do you think rendering Flutter, als…

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 criticize it, you absolutely need to know what you're talking about... if Flutter claims it can handle accessibility, it's on you to prove it can't if you make this argument so eloquently on the Internet without actually knowing it.

BTW if you know of any other good UI Toolkits that really can run anywhere like Flutter, using the same code base, please let me know.

Re: Google Docs will now use canvas based rendering

#718
post #594
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.

It's a task more commonly found in computational geometry (3D range query == find all the points in a data set enclosed by a cube).

There are numerous data structures that are well suited for various geometric queries like ranges/lookups (interval trees, quadtrees) as well as more text-oriented operations like cut/copy/paste/insert/merge/etc (like ropes).

I'm not familiar with the operations required to put a cursor at the right place in a document, but knowing how much research has gone into storing similar data and looking up what you need efficiently the idea of "going through all the text every time" is a big code smell.

Re: Google Docs will now use canvas based rendering

#719
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…

> 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 it could be uplifted to Firefox was extremely annoying). It's also full of security problems, as it's written in '90s C++ that nobody is around to maintain properly. Getting rid of it is an inevitability.

Re: Google Docs will now use canvas based rendering

#720
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…

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

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

This is a great question! I'm not really qualified to answer it, but I'll give it a try.

My understanding is that the XUL tree is fast because it implements the XPCOM C++ nsITreeView[0][1][2] interface.

If you're writing a XULRunner program ...

(Firefox "is distributed as the combination of a Gecko XUL runtime — libxul, other shared libraries, and non-browser-specific resources like those in toolkit/ — plus a Firefox XUL application — mostly just the files in Contents/Resources/browser/, plus the 'firefox' stub executable that loads Gecko and points it at a XUL application", see [3])

..., XPCOM[4] allows you invoke those implemented interface methods directly from JavaScript.

XPCOM is a technology that, since the removal of XUL/XPCOM addons, is inaccessible to everyone except for Mozilla devs and those who write XULRunner programs using `firefox --app /path/to/application.ini`.

So, some XUL elements (like ) implement an XPCOM interface that invokes native C++ (or rust, python, java, etc.) code, which is statically compiled directly into the Gecko XUL runtime.

Modern HTML5 elements, in general, must utilize the native interpreted browser DOM/JavaScript and cannot choose to implement/satisfy an arbitrary internal XPCOM interface. While I'm sure that Mozilla has figured out a way to make these elements fast (C++, Rust, I have no idea), you are always bounded by the limitations of the DOM.

So, my understanding is that, because we are relying on standards-compliant HTML5 elements which mutate the DOM, we cannot specify and implement new XPCOM interfaces ("with a fast C++ API") that could theoretically bypass the DOM — we /must/ rely on the "slow JS API."

[0]: https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/...

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

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

[3]: https://mykzilla.org/2017/03/08/positron-discontinued/#comme...

[4]: https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM

Post reply on HN