4 ms·

CSS Painting API

56 points by 90s_dev 1y ago

90s_dev 1y ago
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
paulryanrogers 1y ago
Why? Nothing in that article makes the use case clear. Perhaps I just lack imagination?
- 90s_dev 1y ago
  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/b6c45f60f6e450574c4087589453e0158d84cbe60ee690f875622ffb19811f66/68747470733a2f2f692e696d6775722e636f6d2f677a537a7861622e706e67 https://camo.githubusercontent.com/b6c45f60f6e450574c4087589... (image taken from the other guy's comment's gh repo)
- dwoldrich 1y ago
  Reusable dynamic canvas code as background image? ¯\_(ツ)_/¯ https://developer.mozilla.org/en-US/docs/Web/API/CSS_Painting_API/Guide https://developer.mozilla.org/en-US/docs/Web/API/CSS_Paintin...
- andrewingram 1y ago
  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.
- c-smile 1y ago
  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.
jauco 1y ago
The most fun I had with this was to make initial versions of apps look alpha using https://github.com/pshihn/rough-paint https://github.com/pshihn/rough-paint
- 90s_dev 1y ago
  Amazing example and show-case, great job. Reminded me of my pinstripes: https://os.90s.dev/#sys/apps/paint.app.js https://os.90s.dev/#sys/apps/paint.app.js https://github.com/sdegutis/os.90s.dev/blob/31bf4ec46e02367b1db4d027922820a267cb153f/site/fs/sys/libs/draw.ts#L3 https://github.com/sdegutis/os.90s.dev/blob/31bf4ec46e02367b... But yours is much fancier and cooler.
hyperhello 1y ago
But you can do this now with Canvas.toDataURL(). Do we need to support another drawing surface API?
- 90s_dev 1y ago
  Using toDataURL() has a lot of overhead that this doesn't use. Also this runs in worklets.
  - Seb-C 1y ago
    Blob URLs should work without much overhead.
    - esprehn 1y ago
      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.
goranmoomin 1y ago
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?
- AgentME 1y ago
  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.
  - MortyWaves 1y ago
    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.
    - AgentME 1y ago
      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.
  - yladiz 1y ago
    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.
reverseblade2 1y ago
Here’s a cross browser example I built for my personal site. See the curve: http://onur.works http://onur.works
- chrismorgan 1y ago
  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. :-(
  - tyleo 1y ago
    Also broken on iOS. Goes off my viewport horizontally. Scroll doesn’t work as expected.
    - reverseblade2 1y ago
      There is scroll snapping. Yes it slightly exceeds the horizontal. My point was about the CSS Painting API though :)
    - reverseblade2 1y ago
      Solved the horizontal viewport.
  - reverseblade2 1y ago
    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.
pjmlp 1y ago
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 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.

56 points by 90s_dev 1y ago

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

paulryanrogers 1y ago

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

90s_dev 1y ago
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/b6c45f60f6e450574c4087589453e0158d84cbe60ee690f875622ffb19811f66/68747470733a2f2f692e696d6775722e636f6d2f677a537a7861622e706e67 https://camo.githubusercontent.com/b6c45f60f6e450574c4087589... (image taken from the other guy's comment's gh repo)
dwoldrich 1y ago
Reusable dynamic canvas code as background image? ¯\_(ツ)_/¯ https://developer.mozilla.org/en-US/docs/Web/API/CSS_Painting_API/Guide https://developer.mozilla.org/en-US/docs/Web/API/CSS_Paintin...
andrewingram 1y ago
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.
c-smile 1y ago
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.

jauco 1y ago

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

90s_dev 1y ago
Amazing example and show-case, great job. Reminded me of my pinstripes: https://os.90s.dev/#sys/apps/paint.app.js https://os.90s.dev/#sys/apps/paint.app.js https://github.com/sdegutis/os.90s.dev/blob/31bf4ec46e02367b1db4d027922820a267cb153f/site/fs/sys/libs/draw.ts#L3 https://github.com/sdegutis/os.90s.dev/blob/31bf4ec46e02367b... But yours is much fancier and cooler.

hyperhello 1y ago

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

90s_dev 1y ago
Using toDataURL() has a lot of overhead that this doesn't use. Also this runs in worklets.
- Seb-C 1y ago
  Blob URLs should work without much overhead.
  - esprehn 1y ago
    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.

goranmoomin 1y ago

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?

AgentME 1y ago
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.
- MortyWaves 1y ago
  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.
  - AgentME 1y ago
    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.
- yladiz 1y ago
  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.

reverseblade2 1y ago

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

chrismorgan 1y ago
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. :-(
- tyleo 1y ago
  Also broken on iOS. Goes off my viewport horizontally. Scroll doesn’t work as expected.
  - reverseblade2 1y ago
    There is scroll snapping. Yes it slightly exceeds the horizontal. My point was about the CSS Painting API though :)
  - reverseblade2 1y ago
    Solved the horizontal viewport.
- reverseblade2 1y ago
  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.

pjmlp 1y ago

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 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.