CSS Painting API | Hacker News Reader

CSS Painting API

developer.mozilla.org

56 points90s_dev24 comments

The most fun I had with this was to make initial versions of apps look alpha using https://github.com/pshihn/rough-paint

Amazing example and show-case, great job. Reminded me of my pinstripes:

https://os.90s.dev/#sys/apps/paint.app.js

https://github.com/sdegutis/os.90s.dev/blob/31bf4ec46e02367b...

But yours is much fancier and cooler.

This is part of Project Houdini from Google, it has been years out there without being picked up by other browsers.

https://developer.chrome.com/docs/css-ui/houdini

Anyone remembers the CSS rendering extensions on IE 5?

That's right, the more things change, the more they stay the same.

If I'm understanding correctly, isn't this introducing a critical dependency on JavaScript during rendering? I get that people might want to draw stuff with code, but why would people use this (and introduce render performance problems inadvertently) instead of using the HTML5 Canvas API?

The HTML5 Canvas API can only be used in the main javascript thread, so whenever the page's javascript thread is busy with anything then the browser has to wait on that to finish before being able to have it update anything it rendered. The Paint Worklets allow the browser to run some page javascript just for rendering in one or more separate threads.

But why can the canvas still only be accessed in the main thread? Why introduce a whole other API as a workaround for this?

Also, as far as I have seen, people have been using WebAssembly for complex stuff and marshalling it to the main thread for the canvas.

The worklet API gives the browser the ability to spawn as many threads for the task as it wants when it wants, without needing to communicate and wait on the page's code in the main javascript thread each time.

It doesn’t refute your point, because a worklet is a worker and thus not in the main thread, but the canvas API is usable outside of the main thread as well, via OffscreenCanvas or something like transferring to a worker.

We came full circle. We started out overriding draw(), then HTML + CSS took over, and now we're back to overriding draw(). This was a huge inspiration for 90s.dev

Here’s a cross browser example I built for my personal site. See the curve: http://onur.works

That’s badly broken in a variety of ways at a variety of window sizes in both Firefox and Chromium, though worse in Firefox where it goes from being unpleasant to downright unusable at some sizes; and at larger resolutions in Firefox it’s not even managing 3fps. What are you doing? You’re meddling with scrolling, too. :-(

Also broken on iOS. Goes off my viewport horizontally. Scroll doesn’t work as expected.

There is scroll snapping. Yes it slightly exceeds the horizontal. My point was about the CSS Painting API though :)

Solved the horizontal viewport.

I am not seeing any issues on Chrome. To be fair, I mostly cared about Safari and Chrome than Firefox.

Scrolling is about scroll snapping feature.

Why? Nothing in that article makes the use case clear. Perhaps I just lack imagination?

Near the top:

> to set complex custom backgrounds on an element

Basically the same reasons you might need draw() in traditional GUIs.

Do this in CSS: https://camo.githubusercontent.com/b6c45f60f6e450574c4087589...

(image taken from the other guy's comment's gh repo)

Reusable dynamic canvas code as background image? ¯\_(ツ)_/¯

https://developer.mozilla.org/en-US/docs/Web/API/CSS_Paintin...

A few years ago I tried to use it to implement mesh gradients. It didn’t go well, mainly because you can’t draw individual pixels without cheating with lots of 1x1px rectangles. But it was a fun experiment.

Consider <textarea> that has resizing handle on the corner (try to reply to this message to see it alive). And now try to imagine how would you render those diagonal lines in HTML/CSS ?

While in Sciter, that has such immediate mode rendering form the very beginning, you can simply draw them as:

   resizableElement.paintForeground = function(gfx) { // draw on top of background & content

      let box = this.getBoundingClientRect();
      gfx.moveTo(...); gfx.lineTo(...);
      gfx.moveTo(...); gfx.lineTo(...);
      ...
   }

Easy, right? And does not need to modify DOM and place artificial positioned elements.

But you can do this now with Canvas.toDataURL(). Do we need to support another drawing surface API?

Using toDataURL() has a lot of overhead that this doesn't use. Also this runs in worklets.

Blob URLs should work without much overhead.

That won't handle resizing properly. This API lets you hook directly into the painting phase of rendering in the browser so you can both draw the correct size without forcing layout and handle resizing. It also gives the browser the flexibility to not paint the off screen content at all.

Reply on news.ycombinator.com