The next step will be that they just send you images.
Google Docs will now use canvas based rendering
641–650 of 953 posts
Re: Google Docs will now use canvas based rendering
#642Earlier quoted context omitted.
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.
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…
The best approach for a desktop first cloud-backed solution is possibly to have a VDI with Windows (on AWS for example), and use Microsoft Remote Desktop from your preferred physical computer to access it.
I have multiple desktop Macs in my various homes but I only use them for web browsing and RDP to the same Windows VDI.
Re: Google Docs will now use canvas based rendering
#643In 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 hard to beat just drawing on a canvas or using WebGL.
Both of these APIs perform quite poorly for what they're doing.
To compete with native, the web platform needs simple low-level APIs that do not have a lot of Javascript marshalling overhead and other performance cliffs. You can always build a more convenient library above low-level interfaces, but the opposite is not true.
Re: Google Docs will now use canvas based rendering
#644In 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 hard to beat just drawing on a canvas or using WebGL. Both of these APIs perform quite poorly for what they're doing. To compete with native, the web platform needs simple low-level APIs that do not have a lot of Javascript marshalling overhead and other performance cliffs. You can always build a more convenient library above low-level interfaces, but the opposite is not true.
They don't need to be better than native, they just need to be better than the DOM plus have the advantages of web-based distribution.
Re: Google Docs will now use canvas based rendering
#645Earlier quoted context omitted.
A million times this - having worked in this space, nobody wants to do this. I understand the cynicism, but the affordances provided by the browser for things like accessibility are very painful to give up. This isn't some dark pattern attempt to cut out whatever "openness" remains on the web, or to convert the browser into a display-streaming client for some sinister DRM reason. In my past job, we rewrote our spread…
> The way to fix this trend would be to reimagine the presentation layer of the browser as something other than a stack of hacks over hypertext, but so far nobody seems to have a good solution. About a decade ago I had the start of a Eureka moment on how to do this (back then — https://medium.com/space-net/spacenet-51aca95d49a2 , nowadays https://treenotation.org/ ). It seems to me we've missed a sort of fundamental…
Hey, nice! I have a notes file experimenting with a similar tree-style minimalist data notation; it's definitely an area that needs more exploration.
I like what you've done with it, I'll need to take a closer look.
While I was thinking about it, I also decided to take a look into prior art, which took me all the way back to Landin's "The Next 700 Programming Languages" from 1966 which introduced the hypothetical language ISWIM, which was the first to introduce indentation based syntax and inspired the ML and Haskell family of languages (https://www.cs.cmu.edu/~crary/819-f09/Landin66.pdf)
It wasn't exactly what I was looking for, but it's fascinating to see how long we've been thinking about these kinds of issues.
Re: Google Docs will now use canvas based rendering
#646Earlier 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…
> 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.
HTML and CSS are fairly well optimized, but dynamic HTML and the DOM were an afterthought. If you could throw out a lot of the guarantees about DOM behavior, you could make a much faster browser, but you'd also break the web.
Re: Google Docs will now use canvas based rendering
#647Earlier 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 really like that scenario, but I don't think market forces are moving towards it.
Then again, we got wasm, and that feels like a miracle in itself.
Re: Google Docs will now use canvas based rendering
#648I wonder if it will help improve ios canvas performance - currently it's somewhere on ie9 level for our use case at least
Re: Google Docs will now use canvas based rendering
#649> ... Over the course of the next several months, we’ll be migrating the underlying technical implementation of Docs from the current HTML-based rendering approach to a canvas-based approach to improve performance and improve consistency in how content appears across different platforms.
This article talks about some of the tradeoffs between Canvas and DOM approaches:
https://www.kirupa.com/html5/dom_vs_canvas.htm
The thing that seems least appealing about replacing DOM rendering with Canvas rendering is the lack of CSS. You may gain performance, but assuming even a fraction of the responsibilities CSS handles so well seems very daunting.
That's why I suspect this approach will do best where the content least resembles a read-only document, and more resembles a game, such as Google Docs.
Re: Google Docs will now use canvas based rendering
#650Earlier quoted context omitted.
Very good point, users do not care that a padding is rounded up or down when they switch from their laptop to their desktop, as long as the application is usable, understandable and visually competent. But mindspace is much more important for interaction, so if their laptop is a Mac, their brain will be in "Mac mode", and "Linux" or "Windows" mode when on their other device. Respecting the platform's conventions will…
I don't think the GP was talking about the app looking consistent with the rest of the platform, but the exact opposite: the app looking the same whatever the platform. Using Flutter allows them to have the app look the same on the browser as on mobile. This means that at best it will look "Mac mode" for everyone, including Windows users; at worst it will look foreign to everyone.
Yes, I understand and agree.
My second paragraph was maybe a bit unclear, I meant that the user would expect platform conventions to be respected over application conventions. (especially if we consider platforms with different primary interactions)