Maybe I'm a small ignorable minority but almost all my library skimming is done on a phone. I explore new technologies when rocking babies to bed or dozing off myself.
And leave scroll bar rendering to the browser or OS vendors!?
Think of the pixels!
/s
Seriously though I believe it's often done to make infinite scrolling and scroll-transitions more visually pleasant. (Not that I agree with the sentiment, but if visuals are more important than anything else...)
I would like a Skia + v8 runtime. Some of my web apps are just a 2d canvas and JavaScript. Would be nice to be able to use them without a browser and bundle with something more lightweight then Electron.
Skia is a graphics engine developed in C++. Think of it as the building block for graphical interfaces, animations and everything else that involves displaying some 2D data on a screen, specially vectorial data.
For example, Flutter uses it to draw its UIs and Chrome uses it for almost everything, including rendering text parsed from HTML. Sublime Text, Firefox, Xamarin and many other projects also rely on Skia for the same sort of thing.
However, unlike, let's say, Qt or GTK+, Skia does not provide already done widgets (i.e., drop-in buttons, windows, text inputs etc.). It's like the fundamental building block on top of which you can create your buttons, animations and everything else and then display it on screen.
Now, CanvasKit is Skia ported to the browser via WebAssembly. Since Skia is a mature project and very performant (as you can guess from who is using it), it's now an alternative to Canvas API and DOM to render things on websites and will also let existing native applications to be ported to the web more easily.
I had a really hard time understanding it as well, and as someone who is supposed to at least have some understanding in this space (HTML5 gamedev) it made me feel a bit dumb.
However, from what I understand, there seems to be two things needed to be noted here:
Skia - a standardised library that can 'render' to different backends - i.e. it can render to OpenGL or SVG or PDFs.
CanvasKit (the actual one linked) - basically use Skia on the web (with webgl).
A huge boon here would be performance. For example, in WebGL, if you want to draw text, the current method is actually to render it in the canvas first, and reupload the texture to the GPU. From what I understand Skia seems to handle the rendering 'natively' so this step is not necessary. So basically it would just make it easier to draw 'primitives' since they are provided by the Skia API without having to do workarounds or writing really low level webgl fragments/shaders.
This is just from what I gathered, but yeah it is confusing. If anyone knowledgeable reads this, let me know if I got anything wrong!
Skia is just a 2D drawing API, like Cairo. It's what Chrome uses under the hood to render their whole UI I think, including (non-WebGL) HTML5 canvas stuff.
Why you would want to use this over HTML5 canvas? Good question. Maybe you want some features in Skia that aren't in the canvas API? Maybe you have a Skia app that you want to port to the web?
I can think of a use case. Writing a GPU accelerated text editor with syntax highlighting that can interface with a back end like neovim. Maybe not super useful but I could see myself doing this since my only expertise is with web technologies.
C/C++ for WebAssembly mainly used for porting existing C/C++ application to the web. I think it is one of them. You know what? Flutter uses Skia as a GUI backend. So maybe we could run a Flutter app using this someday.
That seems like it would have to happen within CanvasKit itself, as the code using it only uses abstractions over the canvas itself. I can't find anywhere in CanvasKit where it does getContext('webgl'), only '2d', so I'm not sure how it's doing it.
The latency of that example seems great with a mouse, and a little laggy with a pen (a bit better than a pure canvas drawing app I've been working on). The frame rate is much better than my app.
I just created a proposal to support lottie based animated stickers in Discourse two days ago, and this looks very useful to get more performance when playing those using the new Skottie module. Very cool!
I can't think of another reason for Google to pour in all those resources (Google apparently being the biggest sponsor and owner of Skia). This could also more generally help give native ChromeOS apps a much needed kick (instead of needing Android apps for so many things).
I'm guessing @pier25 is viewing on a retina (2X pixel density) screen. All the demos are rendered using 1X canvases, so they appear blurry on retina (the default is bicubic interp).
It means you can now include Chrome's Skia vector graphics rendering engine as part of your custom code in WebAssembly (skia/wasm in Chrome or elsewhere).
See the Slug thread from earlier today for context...
Would be terrible if a browser decides to "optimize" the Wasm and upon detection of code that it has natively, directly runs the native version and completely bypasses any security benefits. (If you work on Skia and are reading this, please DON'T compromise on security. We already have too many vulnerabilities on the hardware level thanks to relentless optimizations that was not or unable to be proved correct.)
No browser would ever do this. It's a pain in the ass to do to begin with but it's also an absurdly complex optimization for a specific use case that would barely pay off in practice. It wouldn't work unless you were shipping the same version of skia as the embedded application and you'd have to do all sorts of weird stuff to make the ABIs match up (the native C/C++ ABI is not the same as the one wasm uses at runtime)
The docs say it uses WebGL [1]. And I found a "fixed" pull-request saying it too [2].
WebGL context encapsulated as an SkSurface,
allowing for direct drawing to an HTML canvas.
However, I just discovered this project a few hours ago so I don't know if there's any "gotchas" -- hopefully someone more knowledgeable or on the chrome/skia team will chime in.
As far as I'm aware, browsers have been making use of any available GPU acceleration for rendering 2d contexts since 2012[1]? The example supplied by Google[2] (on the first link) definitely requests a 2d context for the canvas.
There are a few MB of .wasm included in the page. Takes about half a second to load it and another half second to initialize that for me on Chrome/FF. If it's not connection speed related then there is probably something buggy going on with running WASM in your browser.
Would be great if anyone here has some experience with this and examples of use cases. I have been looking at this for a few weeks now for a tile based view with multi threaded rendering and server side prerendering.
But I just can't figure out what the benefits would be over canvas natively, if there even are any. As I wrote in https://news.ycombinator.com/item?id=20339574
"
context: I want to build a tile based view (tiles in x/y dimensions + zoom levels). The content of the tiles is loaded from server (shapes mostly) and rendered into tile images client side. I also want the same tiles prerendered as identical images on the server.
For this I have a feeling that something like skia is the way to go. Skia can be used via wasm bindings. How I would fetch the shapes and render the tiles (or fetch the prerendered ones) transparently and then where to render the tiles into, that is what I am trying to figure out. It feels like multithreading could be very useful here. Right now only chrome appears to support OffscreenCanvas (which can be accessed from webworkers), hence the idea of using skia directly and possibly going a level higher to write whatever kind of multithreaded render logic in rust and run it with wasm and a single "canvas output". Whether skia is the right choice here or not is also something I have yet to figure out
The ultimate goal is quick startup (prerendered tiles) while simultaneously high performance when updating the entire view (=multiple tiles in parallel). This is mostly a learning project for me
context: I want to build a tile based view (tiles in x/y dimensions + zoom levels). The content of the tiles is loaded from server (shapes mostly) and rendered into tile images client side. I also want the same tiles prerendered as identical images on the server.
For this I have a feeling that something like skia is the way to go. Skia can be used via wasm bindings. How I would fetch the shapes and render the tiles (or fetch the prerendered ones) transparently and then where to render the tiles into, that is what I am trying to figure out. It feels like multithreading could be very useful here. Right now only chrome appears to support OffscreenCanvas (which can be accessed from webworkers), hence the idea of using skia directly and possibly going a level higher to write whatever kind of multithreaded render logic in rust and run it with wasm and a single "canvas output". Whether skia is the right choice here or not is also something I have yet to figure out
The ultimate goal is quick startup (prerendered tiles) while simultaneously high performance when updating the entire view (=multiple tiles in parallel). This is mostly a learning project for me
"
Essentially what I am wondering is if using skia via wasm would allow me to bypass limits on canvas natively (and canvas in webworkers) so that I can render multiple tile images in parallel and then draw them into a single view for the user to interact with. Think google maps or similar but tiles rendered client side
Overall this feels like there might be a better way and I am just not seeing it
Just from a brief parse of the code I don't see how the drink could possibly be transforming the way that it is doing. The renderer - drawFrame in this case - isn't doing any heavy lifting to really make all the side animations (drink splash etc) occur.
It appears that at least with this example, possibly the others (the lego one?) if they work they've hidden a lot of data in the fetched json data. Which seems not great. I mean the drink json (https://storage.googleapis.com/skia-cdn/misc/drinks.json) is not human parse-able so I don't see how they made these examples at all. Maybe they made them in Adobe After Effects and then exported the keyframes as json or something, but there's no tutorial or directions that I can see.
This is incredibly frustrating because a decent canvas tool is sorely needed (generally). Does anyone see what is going on?
EDIT: So they do use lottie files (https://lottiefiles.com/410-lego-loader). But lottie files can already be exported to javascript incredibly easily, so unless you really need the extra performance of WASM this doesn't appear to add anything. Am I still missing something?
HTML canvas is incredibly slow and just a generally bad API. Using it from WASM is a mistake. It uses strings for everything and has a particularly slow imperative API, and the spec/de-facto-spec behaviors perform very slowly even on high-end hardware. I've seen relatively simple 2D canvas-based games drop frames in chrome on a GTX 2080ti because canvas is that bad.
The slow downs usually comes from abstraction layers. If you just use the api it will be fast. But if you create 1 million new objects and have 2 million function calls in excess on every frame it will be slow. Eg. If you dont like imperative style it will be slow. A compilation step and a bunch of optimization runs could make anything fast thought.
It really is not. If you want to set the current color you have to assemble a css color string from your color values. There is no way to make this fast. When you ship production 2D games using canvas, stuff like this shows up in your profiles and there's no way to optimize it out other than not using canvas. (Many people switch to using WebGL to do 2D themselves for this reason - it's faster.)
If setting the color is the bottleneck you can for example paint all red shapes, then paint the blue shapes, etc, instead of setting the color for every shape. You can also use different canvases . Offscreen and worker canvases is in experimental which enables further optimizations. 2d canvas has some very expensive calls, the trick is to only call them once, not for each object, not even for each frame. If you have 3d objects eg. Z-index its better to use 3d canvas. Yes 2d canvas is slow, but 2d scenes should be able to be optimized by only painting stuff once, then translate, rotate, reset and reuse. Set some upper limit of moving parts on the screen, then use pooling and caching. Put all canvas calls in the same file/ function then it will be easy to see what code can be removed/re-ordered eg. set the color once, not 1000 times after each other.
There is no guarantee that canvas is hardware accelerated, or how whatever they are optimized, so a low level software rendering library might turn out to execute faster, regardless of the browser.
var anyEl = …;
anyEl.paintBackground = function(gfx) {
gfx.fillColor(rgb(0,0,0))
.rectangle(0,0,100cm,100cm);
return true; // to suppress CSS background drawing
}
paintBackground/Content/Foreground methods are called while rendering HTML tree and the `gfx` passed to that function is the very same graphics that is used for rendering HTML/CSS tree.
That thing allows to combine immediate mode graphics a la ImGui with retained one to achieve more performant solution at the end.
If you want that you will create set of C++ classes wrapping Skia, Direct2D or Cairo with the same API as browser provides.
That is actually what I did in Sciter that is using these libraries for rendering on different platforms - they all have very close feature set - umbrella wrapper is quite simple.
I'm more saying bundlephobia.com is wrong in that it doesn't appear to be including .wasm files at all.
If you just do an npm install of canvaskit-wasm you'll find a 6.4M canvaskit.wasm file. That'd have to be some insane gzip magic to bring that down to 50Kb.
If I gzip the entire canvaskit module (including the font files) I'm getting a size of 3.4M. If I just gzip the .wasm file I get a size of 2.4M.
