Live data from Hacker News

Google Docs will now use canvas based rendering

workspaceupdates.googleblog.com

531–540 of 953 posts

Re: Google Docs will now use canvas based rendering

#531

Earlier quoted context omitted.

Also, you know, accessibility. This could be a real serious problem for people with disabilities.

I'm hoping for a revamped EU accessibility act https://ec.europa.eu/social/main.jsp?catId=1202 that also covers document and office applications, and with GDPR sized fines.

We have to be careful not to throw the baby out with the bathwater here, though. Obviously accessibility is an important issue for both commercial and ethical reasons, but if you're talking about writing laws and severe penalties for breaking them then you will always have to choose what minimum standards you will always require and then accept that it might be unreasonable for a software developer to go further.

For example, suppose the entire purpose of a certain office application is to draw some clever visualisation that helps the office workers to understand complex relationships in their business data. Maybe that presentation style has been chosen based on years of experience and saves a lot of time and avoids a lot of mistakes compared to a simple text report or table of figures. However, maybe it also doesn't work for someone whose vision is too limited to usefully see or interact with the visualisation.

Perhaps you could present the same data and relationships in a different way, a format that would be more amenable to sound- or touch-based interfaces for those with severely limited or no vision. In reality, that might mean writing a second entirely separate application, one that might cost more than the original to implement and support, for an audience that will usually be very small and often empty.

So where should the line be drawn? In an ideal world we want to be as inclusive as possible regardless of anyone's individual limitations, but we also want to provide the most effective presentation possible to those who don't have the same limitations. In general doing both might be prohibitively expensive, so how do you make realistic, ethical decisions in this space, and given that every software application is different, how do you codify the standards you want to make mandatory for the accessibility reasons?

Re: Google Docs will now use canvas based rendering

#532

Earlier quoted context omitted.

The copy and paste problem is sidestepped in android by the os native ocr, it might become common elsewhere too.

I can’t tell if you’re being facetious. Text is rendered to a canvas frame buffer and then the solution to text selection involves OCR?

Cab I be facetious and factually describe the current state of affairs simultaneously?

Re: Google Docs will now use canvas based rendering

#533

Earlier quoted context omitted.

The dom isn't trash. Its good enough. We just need to stop making it do things it wasn't supposed to. That's why things like electron make sense a little bit. Not perfect but sensible.

People are trying to make DOM be a WYSWIG text editor. You're point is dead on. The response is to write an opaque, vendor-specific "DOM". Which is the complete opposite of what HTML was supposed to be. But the browser is now a platform and not a browser, so the metaphors are horribly mixed to the point where I'm not even sure what a DOM is supposed to be anymore.

The DOM was always a WYSIWYG editor – albeit, for HTML, not text. Though, back in the day, HTML was a subset of text with image and table support; none of this fancy `line-height: 1.5em;`…

I wish the web had evolved in a more documenty way.

Re: Google Docs will now use canvas based rendering

#535
post #17

Earlier quoted context omitted.

I think they already have with Flutter

This tech is called CanvasKit, and it scares the shit out of me. Google has, in this case, carefully written a proprietary custom API to take the role of Web Extensions (albeit with far more controls/restrictions/less flexibility) for Docs, but as more and more web properties switch to using Flutter with CanvasKit, we'll see less and less of the web be hypertext, less of the web be scrapeable, less of the web have go…

> The web implies hypertext, the web implies user-agents that fulfill the user's desired agencies.

That's entirely valid for many things people put on the web, but clearly not all. A document editor is not hypertext with agencies fulfilled by the user-agent.

The web now supports a wide range of user experiences, and the "text + links" model is great for a subset of those, but not all. The fact that some apps are moving to a different model to me does not imply any existential threat to apps/sites that do fit well as hypertext.

I see a lot of comments in the thread as essentially arguing that now that UPS using jets to ship packages means that soon they're going to take our cars and bicycles away from us.

Re: Google Docs will now use canvas based rendering

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

Do you think the large performance benefits can be achieved for any general web app (e.g. if I rewrite my Vue app's render functions to using a canvas instead of the DOM) or is the canvas' benefits mainly for niche workloads?

Definitely niche workloads or when the performance benefit from a UX perspective is worth the cost of implementation. Start out with virtualizing the DOM so only the visible parts are showing, if the framerate isn't acceptable after that then consider switching to canvas.

Using the terminal as a case study, its DOM renderer needs to swap out many elements per row in the terminal every frame (the number depends on text styles and character widths) and we want to maintain 60fps. It's also not just a matter of maintaining low fps since more time rendering means less time processing incoming data because they share the main thread, which means commands will run slower.

Re: Google Docs will now use canvas based rendering

#538

Earlier quoted context omitted.

This is making a mockery of accessibility. It's the equivalent of having a company that actively discriminates against everyone not passing a internally developed test to check whether you are a "neurotypical" and then respond to criticism by pointing at the wheelchair ramp you installed on one of your entrances. If I can't copy paste words from your websites to put them into a translator, if I can only use your webs…

You're talking about very different issues of accessibility, one of which is the financial accessibility of client technology and reliable web connection. That is attacked through very different means. For example, FB being free and ad funded addresses that issue; but this is a business model and not a technological standard. Society subsidizing technology is another possibility. But these very serious issues of acce…

HyperText Markup Language is accessible, doesn't require a powerful computer, and can be copy-pasted into a translator.

If your website is unreadable in view-source:, it's probably inaccessible in some way. It's not hard to make an accessible website. If it's hard to make that accessible website look the way you want? Tough luck; hire a competent web designer, or scale back your artistic vision, because you sure ain't sacrificing the ability for people to actually use your website for some pretty colours, are you now?

Re: Google Docs will now use canvas based rendering

#539

Earlier quoted context omitted.

> The primary reason web apps are slow is because the business logic is typically un-optimized. This crops up a lot, shifting the blame from the web technologies to the developers who target those technologies, but where are the exceptions? What's the best example of a large, complex, efficient and responsive web-based application? It's easy to give examples of tragically inefficient and unresponsive web-based applic…

Figma is one of my favorite examples of something which is a nontrivial webapp that avoid feeling like a webapp a lot of the time, even when running in a browser instead of their Electron wrapper. But their technical leadership contains some of the (arguably) most accomplished folks working in the Javascript world these days, they might be an outlier in this area.

It’s easy to forget that Figma is a webapp, until you leave it running in the background and your $2000 computer grinds to a halt.
Post reply on HN