Show HN: Skia-canvas, a browserless implementation of the Canvas API for Node.js

The good things about raqote is that it's a Rust library so it may be safer than Skia. Raqote is also easier to compile than Skia.

The downside is that it's slower than Skia [1].

But, it should be possible to modify skia-canvas to work with raqote. The JS API would stay the same.

[1] https://twitter.com/pcwalton/status/1252281006263988224

This uses the Skia backend instead of Cairo. It will give results closer to Chrome's Canvas implementation.

It also doesn't appear to support Windows yet, whereas node-canvas does.

There's probably other differences, e.g. performance, size, etc. but you'd have to measure them.

Wonder if maybe it has less dependencies, that would be a win. like for example on Mac you need cairo pango libpng jpeg giflib librsvg for Node Canvas. So got to note it down for devs to put on their machines, and then remember to also add the same packages to the containers for deployment or if not using containers install on the server directly. I was playing with Node Canvas ages ago to create placeholder profile pics pngs using a random color background and letter.

I'll be adding more backends to this. I'm almost done with a metal backend (https://github.com/adamnemecek/gpucanvas), I'll add vulkan and wgpu next. If you want to get involved, we are definitely looking for contributors!

It's a really good way to understand 2d graphics.

If by "on different platforms" you mean "on different server platforms" then result will be different but close enough.

On Windows, for example, Skia will render text closer to Direct2D/DirectWrite. On MacOS to CoreText.

For the reference, here is rendering of the same UI (HTML/CSS) in Sciter using Direct2D (left) and Skia/OpenGl (right):

https://sciter.com/wp-content/uploads/2020/09/d2d-vs-skia.pn...

Not the author, but user of Skia on daily basis.

It depends. Skia can either be used as software or GPU renderer.

GPU AA rendering can slightly differs when using MSAA. When MSAA is turned on, Skia has different path renderer strategies (that could be CPU-based, like SDF, or GPU-based using coverage counting). In that case (msaa turned off), AA result should be identical on all platforms, at the cost of performance.

There's headless-gl (https://github.com/stackgl/headless-gl). Note: I'm a maintainer

This is a native dependency where that's compiling skia itself to wasm. The native dependency should be able to be faster by a wide margin by taking advantage of hardware acceleration but it's not obvious if it does (similarly skia compiled to wasm must be much slower than using the proper canvas API in the browser)

It looks like it's MIT licensed, according to their `package.json`.

https://github.com/samizdatco/skia-canvas/blob/master/packag...

1973, with the Xerox PARC-developed Alto personal computer. It's still possible to do today.

Wouldn't that require a browser? What point is the browserless feature? Are non-browser UI applications being used that take advantage of Node.js? Is it for apps?

I have definitely needed this exact functionality in the recent past.

We had an application where a canvas-based editor was used to create diagrams, and then these diagrams were saved to a library. We wanted to have each saved diagram to have a preview image to better visually distinguish between them while scrolling. The ability to render a png on the server from the canvas would have saved us a lot of trouble.

> Why would a drawing API be needed on a server? For headless rendering?

15 years ago I was driving GD and ImageMagick from PHP to render things like staff ID cards, barcode labels for things, etc.

It was trivial to write a script that would render something quickly and just output raw image data, so you could <img src="whatever.php?name=Joe&department=Meat" /> and the image would be dynamically created and sent with the right MIME type.

Plenty of great use cases for this.

I was thinking on creating a turn-based multiplayer game for group chat in an app like Telegram. Then, whenever a player gave a command the server would draw the board and send the updated image to the chat.

It could start with something simple like tic-tac-toe and only two players. A player would tell the app a number between 1 and 9 corresponding to the place he/she chose. Then the server/bot would send the updated image to the conversation.

What do you think? :)

I once built a simple website for a Netflix show where you could enter some text and it'd be played in an animation, but you could also save/share a video of it.

It was so much easier to build the animation in canvas for the site and just replay it to get frames for a video on the server than to try to make the video in some other environment and then show it in the browser.

> Why would a drawing API be needed on a server?

There are plenty of reasons to want to generate an image dynamically on a server. Dynamic image resizing to fit client requirements is one that immediately comes to mind.

I once set up a large bank (you've probably heard of the bank, you've almost certainly not used this specific project though) with server-side Adobe Flex. We were using Flex to display charts on the client, and needed a way to render the same charts for use in reports.

This would be really useful for similar modern projects.

Server Side Rendering is a good use case. If you want to pre-render a data visualization that can be loaded with a web page, you can use something like this in place of the browser's canvas, but use the same code to generate the data visualization

I can totally see myself using it to render PDFs server side (invoices, reports, etc).

I previously worked on an in-browser Hearthstone card renderer that uses Canvas. The rendering needed to be client-side for dynamic use cases (where the card would receive various effects thus change its look).

However I also needed to implement a server-side version of it that prerendered all the cards to PNG so that they're browsable without having clients consume excessive cpu/battery. Doing it using a separate codebase would have been hell to reconcile. Hence node-canvas.

I have built quite a few rendering servers for various use using canvas.js and nodejs. I also built a prototype for a dynamic video rendering server once - also based upon nodejs and canvas.js. It was slow but worked out as a proof of concept that became a fairly successful startup.

You're wayyy off here. There are all sorts of reasons to generate draw images on a server. Just look up imagemagick. And canvas has a much better drawing API and libraries for drawing that would be compatible.

To render all sort of dynamic information:

* visitors counter

* request IP

* game stats in forum signature (implemented this with gd and ruby)

For outputting to static files, like JPEG or PDF.