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

771–780 of 953 posts

Re: Google Docs will now use canvas based rendering

#771

Post by bob1029 »

I've been playing around with pure-canvas web apps that are set up as follows:

  Client -> Server: Raw event stream (keyboard/mouse/touch/resize events)
  Server -> Client: Canvas draw batch stream
The server provides a small javascript shim that bootstraps a websocket & subscribes to all required event sources. It also subscribes to the server issued batch events and has logic to dispatch draw commands to the canvas element.

On the server, I use LMAX Disruptor to aggregate the client events and process them in micro batches (the size of which are determined dynamically based on backpressure). This results in an incredibly low-latency/low-jitter UI. Client events are passed around as readonly structs, so very little allocation or GC is involved throughout (.NET5/C# codebase). Processing is concluded with async/parallel dispatch of the appropriate client-side draw batches as they are ready to be issued. Not all client events result in a draw, and not all client events result in draws on the same client. There are some synchronous concerns between clients in my application, so having a single fast thread allows for lock-free processing of all events at the same time.

The only caveat I have encountered is the latency constraint. Going over ~100ms makes this sort of interface feel like crap. For LAN/localhost, this approach is effectively instantaneous.

Re: Google Docs will now use canvas based rendering

#772

Post by rikarendsmp »

IshKebab wrote: post #769
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…

Try holding down Alt on https://makepad.dev/ Such a cool feature that you can't really do with DOM based solutions (VSCode could never do this).

It may sound stupid, but this was the feature i tried to add to ACE and i couldn't. And i spent the last decade trying to invent a drawing API that would let me do this effect.

Re: Google Docs will now use canvas based rendering

#773

Post by rektide »

munificent wrote: post #758
jl6 wrote: post #602

Earlier quoted context omitted.

Just imagine the sheer glee on the faces of the marketing department when their SEO experts tell them there is a technology that allows them to push pixels in peoples' faces while making it harder for users to engage in "unauthorized content use" and harder to block ads. The web is about to get a whole lot more user hostile.

> there is a technology that allows them to push pixels in peoples' faces while making it harder for users to engage in "unauthorized content use" and harder to block ads. That was exactly true in the Flash days and yet it didn't take over the world or kill the open web.

Flash was small & ignorable enough to block. Nothing significant was lost. The web was winning, easily.

This is the return of Flash, except now, it's backed by Google.

Re: Google Docs will now use canvas based rendering

#774

Post by progval »

azinman2 wrote: post #768
progval wrote: post #714

Earlier quoted context omitted.

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.

But that's not happening, as I'm able to select text on iOS Safari and have it give me the copy/paste options above it. If the text wasn't available, it would also completely break any kind of screen reader / accessibility feature so something has to be supporting this at a native-browser level.

I don't know about iOS, but on Firefox Desktop, the right-click menu is emulated by the canvas, and it uses the clipboard API to copy it.

> If the text wasn't available, it would also completely break any kind of screen reader / accessibility feature so something has to be supporting this at a native-browser level.

When using a screen reader, it tells you you press Ctrl+Alt+Z, which loads an iframe containing (only?!) the first paragraph of the text, so it is made available to screen readers independently.

I have no idea if this would work for editing though.

Re: Google Docs will now use canvas based rendering

#775

Post by larodi »

ska wrote: post #598
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…

> 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. I think this is overly reductive. There was a technical problem driving some of this; namely - document collaboration sucked (to some degree still does). Moving documents online was a tradeoff - making the editor web based solves a bunch of problems but causes some other o…

The way that word processors are designed, essentially as very smart linked-lists of objects, would've actually allowed for the document collaboration very early on. We can perhaps speculate dozens of reasons why dis did not happen, but I guess it was for strategic reasons. But it will and is happening.

Is about right making the point that IMHO the desktop office processor is far from dead, actually I would imagine a comeback of desktop UIs because they are so much easier to get right, especially when you have complex forms (which all business software has) or custom GUIs (such as those in software like Blender, Photoshop, Lightroom, etc).

Question is did people really needed the collaboration feature so much, or as much as it was praised for decades... When it shows that source code (which IS one very important content) is being developed not collaboratively in real-time in the browser, but with the aid of various version control systems (CVS, SVN, GIT etc.) that is neither real-time, nor collaborative in the sense that Google DOX is.

So the whole collaboration thing is fun to have, great thing to demo, but perhaps not the killer feature.

Question is whether other features were more important and thus got implemented in the office packages. Such as enterprise integration capabilities and very powerful and well crafted WYSIWYG that is only possible with custom built engine.

Let's be honest - the most complex apps that is typically running on an average desktop OS is the browser and the word/spreadsheet processor. Back in the day the browser was not a VM and was not that complex. And as OpenOffice showed - this is not very easy to get right. As WPS Office (the Chinese office) showed - even if the presentation layer is fast/correct, it is not really that easy to (originally) come up with it nor integrate it with other enterprise services.

One may wonder whether MS Office was created to run best on Windows, or was it that Windows is made so to enable good run of MS Office and the integration of all this mandatory software that constitutes the modern enterprises... (again, trying to be as unbiased as possible)

Re: Google Docs will now use canvas based rendering

#776

Post by snewman »

bhl wrote: post #757
snewman wrote: post #736

Earlier quoted context omitted.

This is why I love HN. :-) However, I can't claim credit (or blame, but I would argue mostly credit) for that code. There have been three generations of the Docs editor that I know of: 1. The original, which I was involved in, was an unholy mess perched shakily atop contenteditable. As such, it contained no layout or rendering code (but did all sorts of horrid things under the hood to massage the HTML created by the…

With a canvas-based engine, the editor is no longer relying on the contenteditable spec right? For the majority of use cases, do you think contenteditable + view layer which precisely updates the HTML is still viable? More specifically, what do you think about open-source libraries like ProseMirror ( https://prosemirror.net/ ) or Slate.js ( https://github.com/ianstormtaylor/slate ) which do that (ProseMirror uses its…

> With a canvas-based engine, the editor is no longer relying on the contenteditable spec right?

Correct. In fact, contenteditable went out the window a decade ago when the "#2" engine (low-level DOM manipulation) was launched.

My experience with contenteditable is ~12 years stale at this point, so the only thing I'll try to say is that I expect it would work well up to a certain level of ambition, and no further. As I say above regarding frameworks: they're great so long as your requirements fit within the expectations of the framework, but you quickly hit a wall if you need to stray outside of that. For Docs, the desire for a paginated view/edit mode was an example; there was simply no sane way of squeezing pagination into a contenteditable-based engine.

Re: Google Docs will now use canvas based rendering

#777

Post by rikarendsmp »

slaymaker1907 wrote: post #638
skyde wrote: 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?

Did you try using dev/canary Edge? It should pretty much be the same rendering engine and JS engine as Chrome. Definitely report this to the Edge team if you have the time (very easy to do from the dev version of Edge). In my experience, they are very responsive to bug reports and feature suggestions.

Back in the day i made it work on Edge on an xbox. This was microsofts browser +JS engine. Nowadays its just chrome though. If it has problems, i'd be highly surprised.

Re: Google Docs will now use canvas based rendering

#778

Post by bhl »

neurostimulant wrote: post #260
jpeter wrote: post #204

Earlier quoted context omitted.

Even has fake text search. Not bad.

Browser's built-in search feature (e.g. "find in this page..." on firefox) doesn't work though.

Given for a text editor, find-and-replace is a feature anyways that's not natively supported by contenteditable.., you will need to build out a custom app search feature anyways. But yeah, for preview only mode, sad to see native features not work on a static document.

Re: Google Docs will now use canvas based rendering

#779

Post by snewman »

xattt wrote: post #729
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 have nothing to add to the discussion, other than I’ve been using Writely since ~2005-2006 and wanted to say thanks for all the fish! It was super handy before I had a laptop for regular use. I used it at public libraries for projects in my last year of high school. It helped me develop a habit of having a third-space workplace that was away from home and school.

Thanks!

The "floating workspace" aspect has always driven at least as much usage as the "collaboration" aspect. That came as a complete surprise to us, but it turned out to be very important to adoption. At some point I think we determined that the average document had something like 1.1 collaborators.

Re: Google Docs will now use canvas based rendering

#780

Post by jl6 »

munificent wrote: post #758
jl6 wrote: post #602

Earlier quoted context omitted.

Just imagine the sheer glee on the faces of the marketing department when their SEO experts tell them there is a technology that allows them to push pixels in peoples' faces while making it harder for users to engage in "unauthorized content use" and harder to block ads. The web is about to get a whole lot more user hostile.

> there is a technology that allows them to push pixels in peoples' faces while making it harder for users to engage in "unauthorized content use" and harder to block ads. That was exactly true in the Flash days and yet it didn't take over the world or kill the open web.

Canvas is more capable than Flash, it’s supported by everything already, it’s well sandboxed, it’s apparently faster than the alternatives, the technique in question now has the backing of a powerful industry leader, and the underlying technology is an open standard so it’s even got moral high ground.

And it’s possible we only managed to escape Flash-hell thanks to the fortuitous self-interest of Apple, so let’s not be complacent by assuming we’ll escape the next trap.

Having said all that, I actually like the idea of separating web applications from web documents and I don’t at all begrudge web application developers from doing what it takes to improve their applications. I just know it will be abused. The best I can hope for is that it leads to some re-focus on HTML as a stable and finished document language.

Post reply on HN