Making the whole web better, one canvas at a time

Note that OffscreenCanvas is currently only implemented in chromium based browsers [0]<p>It is a neat idea, basically separating all the canvas calls into a webworker so it can run on it&#x27;s own thread. However this scale of parallelism is not a solution to fundamentally slow code... the map rendering performance is still poor, it&#x27;s just been prevented from interfering with the main thread. Please don&#x27;t throw web workers at stuff before asking why the code or API calls are slow first.<p>[0] <a href="https:&#x2F;&#x2F;developer.mozilla.org&#x2F;en-US&#x2F;docs&#x2F;Web&#x2F;API&#x2F;OffscreenCanvas#browser_compatibility" rel="nofollow">https:&#x2F;&#x2F;developer.mozilla.org&#x2F;en-US&#x2F;docs&#x2F;Web&#x2F;API&#x2F;OffscreenCa...</a>

&gt; What&#x27;s interesting though, is that in reality, &lt;canvas&gt;&#x27;s prevalence in the the HTTPArchive isn&#x27;t so far behind &lt;video&gt; (63rd&#x2F;70th most popular elements respectively). It&#x27;s considerably more widely used than many other standard HTML elements.<p>&gt; Amazing, right? I mean, how could that even be?!<p>&gt; The short answer is, it&#x27;s just harder to recognize. A great example of this is maps. As a user, you recognize maps. You know they are common and popular. But what perhaps you don&#x27;t recognize that it&#x27;s on a canvas.<p>I’d posit that the majority of canvases in the wild is tracking and fingerprinting, not something that ends up visible to the user.<p>Unfortunately, privacy-conscious users are best off blocking canvas by default, like Tor Browser does.

Canvas is one of the only web APIs that&#x27;s simple enough to understand in one reading, yet flexible enough to be a real application primitive — and that&#x27;s because it wasn&#x27;t originally designed for the web, but was simply a lightweight wrapper around CoreGraphics for Apple&#x27;s Dashboard in Mac OS X.<p>Maybe Apple should have provided an NSView wrapper too, with a drawRect() method to draw into a canvas, and made DOM elements part of that view tree. That would have been a much simpler API for web components than what the committees came up with.

I have been disappointed by cross browser discrepancies in the canvas element. Chrome and FF handle Alpha values very differently, and the results are extremely noticeable if you do anything that involves layering many semi-transparent layers on top of each other. There are other floating point rounding error quirks as well, e.g., firefox can translate a context by 0.001px whereas chrome is limited to a precision of only 0.01px. These discrepancies make it impossible to do certain things that look the same on all browsers.

For a high performance&#x2F;responsive 2D canvas the best approach is with webworkers and ArrayBuffer, like I did for this project:<p><a href="https:&#x2F;&#x2F;rockingship.github.io&#x2F;jsFractalZoom&#x2F;jsFractalZoom.html" rel="nofollow">https:&#x2F;&#x2F;rockingship.github.io&#x2F;jsFractalZoom&#x2F;jsFractalZoom.ht...</a><p>It can easily handle 4K resolution.

OffscreenCanvas isn&#x27;t supported by Firefox yet. Also, if a canvas is just not attached to display it can act like offscreen canvas. Drawing on it will be much faster than on screen canvas. When you are done drawing, take the image data from offscreen canvas and draw on the live canvas.

Seeing canvas used always makes me sad. Why can’t maps use SVG? If there are blockers for that, I’d rather see the web resolve those. canvas is a black box for screen readers, crawlers, the semantic web. You end up reimplementing a DOM anyway for accessibility, or not, if you don’t care about accessibility, which sucks.

Back in the day we used to call that &quot;double buffering&quot;.<p>The common Amiga implementation was especially neat. There, the video buffer was (almost) any chunk of memory you pointed the &quot;screen&quot; at. You could pre-render a number of complex frames, and have a high-FPS animation by moving the buffer pointer.<p>And yes, you could look at your own code executing in realtime. But I digress.

I don&#x27;t understand. Was it not possible to decouple the UI&#x2F;events thread from whatever performance intensive things your app might be doing? We&#x27;ve had HTML5 games for a long time now and they&#x27;ve figured this out.<p>Is this just a batteries-included way of forcing the thread separation between logic and drawing?

The linked video demo is really impressive <a href="https:&#x2F;&#x2F;youtu.be&#x2F;8aAdP9nQSss?t=303" rel="nofollow">https:&#x2F;&#x2F;youtu.be&#x2F;8aAdP9nQSss?t=303</a> (rendering a mandelbrot from barely usable to fully responsive and animated)

Nice to see the webkit demo, though unfortunately offscreencanvas is not yet supported on mobile or desktop safari<p><a href="https:&#x2F;&#x2F;caniuse.com&#x2F;offscreencanvas" rel="nofollow">https:&#x2F;&#x2F;caniuse.com&#x2F;offscreencanvas</a>

I wish the article would have some code examples.

nice, sounds like double-buffering [1] for canvas is finally a viable option.<p>[1] <a href="https:&#x2F;&#x2F;www.khronos.org&#x2F;opengl&#x2F;wiki&#x2F;Default_Framebuffer#Double_buffering" rel="nofollow">https:&#x2F;&#x2F;www.khronos.org&#x2F;opengl&#x2F;wiki&#x2F;Default_Framebuffer#Doub...</a>

Good time to be a Flutter developer. I’m really excited to see where they can get on web in particular in the next couple of years but this will certainly help.

It&#x27;s nearly _good_. Still a bit janky imo