Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Skia Canvas: Browserless implementation of the HTML Canvas drawing API for node

skia-canvas.org

Post reply on HN
Print view View original

81–90 of 91 posts

Re: Skia Canvas: Browserless implementation of the HTML Canvas drawing API for node

#81

Post by silvajoao »

njtransit wrote: post #62
silvajoao wrote: post #53

https://windowjs.org is a very similar concept -- it wraps Skia and exposes it as the Canvas API, but also embeds v8 for a very small runtime instead of using Node. It was my first open-source project, released about 3 years ago. I had plans to also expose WebGL, audio, etc and make it a viable platform for Javascript-based games on desktop. Life and other projects happened instead, and development was discontinued.…

That’s pretty cool! But v8 alone kind of sucks unless you specifically want isolation. Sometimes you just want to make a network request, you know?

That makes total sense in many applications, including games.

The idea was to have TCP sockets and Websockets to enable that.

Basically, have the same APIs you're familiar with in a Browser, but in a much smaller package that you can ship independently of the Browser.

(this is very similar to Electron)

Re: Skia Canvas: Browserless implementation of the HTML Canvas drawing API for node

#82

Post by epcoa »

pjmlp wrote: post #75
epcoa wrote: post #23

Earlier quoted context omitted.

There isn’t really anything commonly “native” as powerful as skia for 2D drawing and a big part of skia is using the native graphics effectively, this is why it exists in the first place for browser engines. Besides having one target API is a benefit.

Direct2D, CoreGraphics,...

In addition to the portability issue, CoreGraphics does not compete directly with Skia or Direct2D for that matter (it’s mostly CPU based). If you combine it with CoreAnimation you get something of a quasi superset. Direct2D is +/-, but it also doesn’t have some higher level features like PDF and SVG backends, and it doesn’t have the software rendering capabilities of skia by design.

Of course there are 2D drawing libraries on the major platforms (and CoreGraphics and Direct2D are very different, there’s also GDI+), but it was a weird question to start: what’s the use of a portable library. But furthermore, skia is not just a portability wrapper.

Re: Skia Canvas: Browserless implementation of the HTML Canvas drawing API for node

#83

Post by vjeux »

h1fra wrote: post #19

Out of curiosity, what's the use for such library? If you are on a desktop surely there is a better native library to draw shapes, no?

We use it for excalidraw to generate opengraph previews of scenes when you send a link to somebody.

Re: Skia Canvas: Browserless implementation of the HTML Canvas drawing API for node

#84

Post by citeguised »

I'm using this currently with Deno for Advent of Code, if I need a simple window with graphics. (There's a window-example[1])

It can be added by doing "deno add npm:skia-canvas", adding "nodeModulesDir: auto" to the deno.json, and doing a "deno install --allow-scripts".

[1] https://skia-canvas.org/#rendering-to-a-window

Re: Skia Canvas: Browserless implementation of the HTML Canvas drawing API for node

#85

Post by DaniAkash »

vjeux wrote: post #83
h1fra wrote: post #19

Out of curiosity, what's the use for such library? If you are on a desktop surely there is a better native library to draw shapes, no?

We use it for excalidraw to generate opengraph previews of scenes when you send a link to somebody.

That's so interesting! So it's a great way to display og:images for canvas items

Re: Skia Canvas: Browserless implementation of the HTML Canvas drawing API for node

#86

Post by wis »

silvajoao wrote: post #80
wis wrote: post #70

Earlier quoted context omitted.

Amazing project! > but also embeds v8 for a very small runtime instead of using Node. By how much does embedding just V8 instead of using Node.js decrease the binary size? Node.js uses V8, does most of Node's binary size come from its runtime and not V8? I tried browsing the website and GitHub repo to find how many kBs or MBs typically is a Window.js binary, but didn't find an answer.

See the binary sizes in the (obsolete) releases page: https://github.com/windowjs/windowjs/releases About 8 MiB in the end. Note that these builds have a binary trimmed by UPX.

Wow, 8 MiB, that's impressively small IMO. I expected a program that embeds V8 (let alone also having windowing and Skia) to have a binary size much bigger. something closer to Node's or Deno's binary size 40MiB+.

Using the Window.js approach of embedding V8, instead of using a windowing library + a Skia Canvas library in Node.js ─really makes sense if you would like to keep the binary size minimally small and only pay for the libraries/modules you actually pull in and use, instead of having them statically linked in the binary by default. For example, an offline app/game that doesn't use the network doesn't need to have a "net" or "http" module in the binary. These may be bad examples though, I don't know how much do those Node runtime modules constitute out of the final Node binary, it may be an insignificant fraction.

Re: Skia Canvas: Browserless implementation of the HTML Canvas drawing API for node

#87

Post by dizhn »

adrianh wrote: post #37
h1fra wrote: post #19

Out of curiosity, what's the use for such library? If you are on a desktop surely there is a better native library to draw shapes, no?

At Soundslice, we have a custom sheet-music-rendering graphics library in frontend JavaScript/Canvas. We also need to generate vector PDFs serverside — so we use a node library that speaks the HTML Canvas API and can generate PDFs. This way the result is exactly the same as the rendered sheet music in the web browser. Nice! The upshot is: this kind of library allows for code reuse in non-browser contexts.

I have a soundslice account that I use infrequently. It's pretty nice. Thanks for building it and making it available.

Re: Skia Canvas: Browserless implementation of the HTML Canvas drawing API for node

#88

Post by pjmlp »

epcoa wrote: post #82
pjmlp wrote: post #75

Earlier quoted context omitted.

Direct2D, CoreGraphics,...

In addition to the portability issue, CoreGraphics does not compete directly with Skia or Direct2D for that matter (it’s mostly CPU based). If you combine it with CoreAnimation you get something of a quasi superset. Direct2D is +/-, but it also doesn’t have some higher level features like PDF and SVG backends, and it doesn’t have the software rendering capabilities of skia by design. Of course there are 2D drawing li…

Well, the whole point is the native 2D library on the OSes that Skia depends on, APIs that take direct advantage of OS 2D and 3D OS APIs, and not some third party.

Re: Skia Canvas: Browserless implementation of the HTML Canvas drawing API for node

#89

Post by epcoa »

pjmlp wrote: post #88
epcoa wrote: post #82

Earlier quoted context omitted.

In addition to the portability issue, CoreGraphics does not compete directly with Skia or Direct2D for that matter (it’s mostly CPU based). If you combine it with CoreAnimation you get something of a quasi superset. Direct2D is +/-, but it also doesn’t have some higher level features like PDF and SVG backends, and it doesn’t have the software rendering capabilities of skia by design. Of course there are 2D drawing li…

Well, the whole point is the native 2D library on the OSes that Skia depends on, APIs that take direct advantage of OS 2D and 3D OS APIs, and not some third party.

Are Vulkan and OpenGL OS “native” or 3rd party? I think this is sort of a semantics hairsplitting argument that isn’t terribly useful.

Skia is useful because it provides a powerful, performance oriented common target 2D drawing library, and it is more than a lowest common denominator wrapper.

Re: Skia Canvas: Browserless implementation of the HTML Canvas drawing API for node

#90

Post by pjmlp »

epcoa wrote: post #89
pjmlp wrote: post #88

Earlier quoted context omitted.

Well, the whole point is the native 2D library on the OSes that Skia depends on, APIs that take direct advantage of OS 2D and 3D OS APIs, and not some third party.

Are Vulkan and OpenGL OS “native” or 3rd party? I think this is sort of a semantics hairsplitting argument that isn’t terribly useful. Skia is useful because it provides a powerful, performance oriented common target 2D drawing library, and it is more than a lowest common denominator wrapper.

They are on the platforms that offer them as OS APIs, Skia isn't, it is a wrapper on top.

It could be Qt, SDL, SFML, or anything else with similar goals.

Post reply on HN