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

691–700 of 953 posts

Re: Google Docs will now use canvas based rendering

#691

Post by breck »

lambda wrote: post #681
breck wrote: post #656

Earlier quoted context omitted.

Yes, and surprisingly there are not too many that use any indentation based syntax (about 1 in 50). However, of the ones that do (abc, aldor, boo, buddyscript, cobra, coffeescript, csl, curry, elixir, f-sharp, genie, haml, haskell, inform, iswim, literate-coffeescript, livescript, madcap-vi, madcap, makefile, markdown, miranda, nemerle, net-format, nim, occam, org, promal, python, restructuredtext, sass, scss, spin,…

Cool! Thanks for some more reading and inspiration. Here's what I have in my notes buffer; I hadn't gotten much further than this. Ssn: /([0-9]{9})|([0-9]{3})-([0-9]{2})-([0-9]{4})/\1\2\3/ People: Table first: String last: String dob: Date ssn: SSN Csv headings: True load people.csv as: People select first last dob filter dob.age > 21 Well, I had some discussion, alternate forms of the syntax, links to prior art, etc…

Very nice! The nice thing about these kinds of notations is that they last. Simplicity is timeless. I can immediately grok exactly what you are doing here. :)

Re: Google Docs will now use canvas based rendering

#692

Post by 411111111111111 »

aloer wrote: post #683
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…

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?

There were a few really interesting blog posts about the architecture choices for the xi editor a few years ago, ending with this

https://raphlinus.github.io/xi/2020/06/27/xi-retrospective.h...

But I personally never worked on this kind of problem, I just remember reading these over the years

Re: Google Docs will now use canvas based rendering

#693

Post by coffeefamine »

cphoover wrote: post #78
lewisjoe wrote: post #30

We are working on a full-featured Google Docs alternative - https://writer.zoho.com . We are already capitalizing canvas technology for rendering documents across devices, except for the Web which still is DOM. Having a single codebase that renders across all platforms is our long-term motive, and it does require rendering to a cross-platform canvas backend - like Skia. I'm assuming Google Docs is already on that dir…

I love zoho's suite of free tools. When I first got started in web development business 10+ years ago, I used their invoicing tool, and thought it was perfect for a freelancer like I was at the time.

As a small business owner, I found refrens.com extremely useful for invoicing.

Re: Google Docs will now use canvas based rendering

#694

Post by MaxBarraclough »

Leherenn wrote: post #576
moshmosh wrote: post #89

Earlier quoted context omitted.

I would agree that companies have mostly settled on paying 20% as much for development, at the cost of 5-10x the memory footprint and 5-10x the input latency in the finished program. I think the web tends to get hit the hardest by that because if a company is targeting the web for an "app" in the first place, they've already chosen cost savings over performance and UX, so they'll be prone to make even more trade-offs…

I disagree, I prefer to Google something and have it instantly in my browser instead of having to find and install yet another app, then uninstall it when I'm done with it. Especially for stuff I only use once/rarely. Also, I might be using the latest iPhone, an old Android, Windows or Linux, or hell maybe my TV browser, and it's most likely going to work. The app wouldn't exist on at least half those platforms. Ther…

You're right that the web scores extremely well on portability and on having zero installation hassle. The points about efficiency still stand though. To put that another way: the web's upsides are real, and so are its downsides.

Re: Google Docs will now use canvas based rendering

#695

Post by BlueTemplar »

hctaw wrote: post #329
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…

I feel the need to argue that the browser is not the browser engine. An app sitting in a chrome tab is significantly different than an app built on electron, they just share some rendering code paths. Electron apps have shown that you can use a browser's rendering engine to make high quality apps distributed on multiple platforms. They also have the benefit of persistence, filesystem access, hooks into native code sh…

An app sitting in a chrome tab also shares its user interface, which is a problem when your app starts deviating from a simple HTML document.

Re: Google Docs will now use canvas based rendering

#697

Post by stdgy »

DaiPlusPlus wrote: post #151
disease wrote: post #88

Earlier quoted context omitted.

I think this is the real reason for the change as well. A few years ago Visual Studio Code underwent a similar change where rendering the terminal moved from using DOM to canvas. I never noticed a huge difference between the two methods but I imagine using canvas gave them a lot more flexibility in addition to being more performant.

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

Document display and document editing are rather different tasks. The DOM was built for the display of static documents. Dynamism was slowly added over the years through JS, and eventually CSS (animations, transformations, etc). But the underlying purpose of the browser rendering engine has remained the same, which is to display static documents. It's not surprising that a client built from the ground up around the concept of displaying static documents doesn't do a good job of allowing users to edit documents in a WYSIWYG kind of way. That has never been its job!

Re: Google Docs will now use canvas based rendering

#699

Post by BlueTemplar »

hctaw wrote: post #43
jhartmann wrote: post #25

Earlier quoted context omitted.

Performance of DOM based rendering is very problematic and not unified across browser implementations. Canvas rendering will likely increase the performance of Google Docs, and make the UX more unified across platforms. Google Docs is really an application built on the web platform. HTML DOM rendering was never intended to give developers the control they need to build fully featured high performant applications, we…

Microsoft Word, Pages and Open Office don't seem to be bottlenecked by rendering performance like Google Docs. Perhaps the browser is the wrong platform for document editing.

The browser is the wrong platform for anything that isn't an HTML document, and not only for performance reasons, but perhaps much more importantly : for interface reasons.

For instance : in your typical windowed program, when you press "Alt", it's supposed to show the Menu, which you can then quickly navigate using keyboard shortcuts. You can't do that properly inside the browser because it's going to conflict with the browser's own Alt-Menu.

Re: Google Docs will now use canvas based rendering

#700

Post by rikroots »

IceHegel wrote: post #422

As someone who's never worked with canvas, I'm now curious about how it works. What is the workflow like for rendering text? Under the hood, is canvas implemented using WebGL APIs or do browsers have their own separate implementation for canvas?

The canvas 2D API[1] has support for rendering text, but it is ... limited. For instance, there's no inbuilt multiline support. Which means that if you're serious about rendering text to the canvas, then you have to reimplement a whole host of things yourself in Javascript.

Another worry is that browsers have an inconsistent approach to interpreting `ctx.font = "CSS font string"` - Safari, for instance, does not support the 'bold' keyword; the only way to get that browser to display bold text is to supply it with an already emboldened font.

However with a lot of work, it's possible to do some amazing things with text. Below, links to a couple of demos of text rendering using my own canvas library[2][3].

[1] I highlight the 2D engine because the Google Workspace team specifically linked to the W3C HTML Canvas 2D Context specs in their announcement. I understand that rendering text in the WebGL context is far more complicated. https://www.w3.org/TR/2dcontext/

[2] https://scrawl-v8.rikweb.org.uk/demo/canvas-017.html - Phrase entity: test lineHeight, letterSpacing and justify attributes. Section classes functionality

[3] https://scrawl-v8.rikweb.org.uk/demo/canvas-018.html - Phrase entity - text along a path

Post reply on HN