841–850 of 953 posts
Earlier quoted context omitted.
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).
Would anyone mind explaining/screenshotting what it does, for the benefit of those of us on phones?
EDIT: Hmm, it actually works, at 125% DPI and various browser zoom levels, the text isn't blurry. Maybe that's linked to how the page doesn't change size when you resize your window.
Earlier quoted context omitted.
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.
Well, it’s clearly what the Google docs team wants. And it would yield higher performance for other similarly complex web apps (eg Figma). And allow native UI development in more languages (Blazor). It also looks to be the sort of thing the Flutter team want for web builds. And it could work well for the base system of chromeOS too. For whatever reason, Google invests hundreds of millions each year into chrome, and t…
Earlier quoted context omitted.
>Both of these APIs perform quite poorly for what they're doing. When it comes to Canvas, do you mean that it actually performs poorly when putting pixels on the screen using putImageData, or do you mean that it does that fine but it performs poorly when it comes to drawing vector graphics? In either case, do you know why it performs poorly? Personally, I would be happy if Canvas just let you put raw pixel data on th…
It performs poorly in either case. For one, Javascript APIs have significant marshalling overhead. Secondly, Canvas is often "hardware-accelerated", which can make some things faster, but also slower because this kind of immediate-mode drawing doesn't match the GPU interface well. It's particularly slow at vector graphics. Some effects would require pixel readback, which is slow for the same reason. > Personally, I w…
https://developer.mozilla.org/en-US/docs/Web/API/HTMLCanvasE...
One would assume/hope that specifying "bitmaprenderer" for the context type would give you a regular immediate-mode CPU rasterizer. Is that not the case?
> Getting arbitrary data into such a Bitmap is slow, so if you want to do it every frame you may run into issues.
To expand on this, doing that ("putting raw pixel data on screen") anywhere is slow if it's modified regularly. There just doesn't exist a fast CPU-buffer-to-display pipeline anymore, that died out years & years ago. So that one at least isn't a JS/web limitation, it's more a modern graphics architecture one. You just can't bit-bang pixels yourself anymore, not reasonably efficiently anyway. In theory that'd be possibly on unified memory architectures (read: mobile devices & integrated graphics), but GPUs don't like to publish their swizzled texture formats so you still don't get to even there.
I don't build extensions or work on much front end web lately but this reads like Google wants more control over their stuff. The web is becoming less open. > By moving away from HTML-based rendering to a canvas-based rendering, some Chrome extensions may not function as intended on docs.google.com and may need to be updated. > If you are building your own integrations with Google Docs, we recommend using Google Work…
In this case, I think the switch is most likely entirely based on technical merits, rather than some way of asserting more control. So with that in mind, the fact that the team behind one of Google's most interactive pieces of software has to throw up their hands and say "DOM is too slow, we gotta roll our own" should be a wakeup call for everyone working on Chrome and other browsers, but mostly for Google itself. Wh…
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 had no idea what I was doing and thinking that using JavaScript to manipulate the DOM was going to be slow, I chose ActionScript and Flash as the language and runtime to develop the project in. I wrote a client-side expression parser and formula engine, and managed to develop a functioning spreadsheet UI with resizable rows and columns, copy and paste with Excel-like animations, cell references etc.
The problem that I ran into was text-rendering when there was a lot of text on the screen. The application would consume a lot of memory and the page would slow down to a crawl when scrolling. I couldn't really find a way to speed up the performance and stopped working on the application after some time. That's when I realized the incredible amount of work that went into Google Docs and other web-based spreadsheets. :)
Earlier quoted context omitted.
This isn't entirely the fault of Electron though, but the convenient data types exposed in a web environment. Beyond the baseline memory of running Chromium, you could use various tricks to keep memory very low such as minimizing GC (eg. declare variable up front, not within loops), use array buffers extensively, shared array buffers to share memory with workers, etc.
> eg. declare variable up front, not within loops I have trouble believing modern JS engines wouldn’t optimize this to the same thing.
But it's really easy for escape analysis to fail, it has to be conservative. So you can end up heap allocating a temporary object every loop iteration quite easily.
I don't build extensions or work on much front end web lately but this reads like Google wants more control over their stuff. The web is becoming less open. > By moving away from HTML-based rendering to a canvas-based rendering, some Chrome extensions may not function as intended on docs.google.com and may need to be updated. > If you are building your own integrations with Google Docs, we recommend using Google Work…
Did you feel the same when Maps went from HTML to Canvas? There is no factual basis for your claims. The simplest and most obvious answer is performance. Docs these days can take 5-10s to fully open, especially with comments and annotations.
* How many browser functions will break.
* Will middle click still work.
* Will screen readers still work?
* Will search engines/ctrl+f still work?
One of the awesome things about web browsers is you get so many features for free on every website. Making the text bigger on a website mostly just works everywhere while on traditional apps it only does if the app has a specific setting for it.
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…
The name Writely reminds me of a side project I worked on around 2010. I was not satisfied with the performance of Google Docs and its competitors at the time like EditGrid and thought (naively, as it turned out) I'd be able to develop a faster alternative. I had no idea what I was doing and thinking that using JavaScript to manipulate the DOM was going to be slow, I chose ActionScript and Flash as the language and r…
Earlier quoted context omitted.
Did you feel the same when Maps went from HTML to Canvas? There is no factual basis for your claims. The simplest and most obvious answer is performance. Docs these days can take 5-10s to fully open, especially with comments and annotations.
I think the panic over this is a little unfounded. For docs this makes perfect sense. My concern I guess is if this becomes the normal way of doing development, and people build HTML replacements that work using canvas. What will the impacts be. * How many browser functions will break. * Will middle click still work. * Will screen readers still work? * Will search engines/ctrl+f still work? One of the awesome things…
It's definitely not easy, it requires you to re-implement everything from scratch. It only makes sense in cases where performance is paramount. I could imagine applications being migrated to the web doing it though, like Photoshop an the like.
But I absolutely don't see normal web development migrating over, it's just way too much pain for little value. Development, debugging, testing, etc. Everything becomes much harder.