5 ms·

You've always been able to use a canvas normally and then create a url to it using toDataUrl. Alternatively toBlob then createObjectURL which I think might be m

by zawerf 9y ago

You've always been able to use a canvas normally and then create a url to it using toDataUrl. Alternatively toBlob then createObjectURL which I think might be more performant than data url which requires encoding/decoding base64. So I guess the main thing added is convenience? Am I missing something here? Adding CSS that requires corresponding JS code is also new territory isn't it (I can't think of anything else that does this)?

zitterbewegung 9y ago
Embrace , extend and extinguish. Either that or developer ergonomics . Most likely the latter.
- zawerf 9y ago
  Developer ergonomics is good. I still remember days where you had to use images for shadows and round corners. Now it's just one line of CSS. But here it doesn't feel very ergonomic. You still need to write that JS code! Reading into it some more I think the only benefit it adds is state management (rerender on parameter change) but I don't really don't want/need CSS doing that for me.
untog 9y ago
It says that it'll re-run the code on resize, which is a lot easier than using a canvas manually then listening for window.onresize or something. And I suppose supplying the parameters in CSS instead of via a separate JS call is nice? Also, the mention of rendering off-thread in the future is pretty great, and not possible with current methods.
vertex-four 9y ago
I believe this could avoid at least one copy of the canvas's buffer from the graphics card to the CPU and back again - which might be useful for animation performance? Also, yeah, it's a more "obvious" way of doing this - instead of rendering to an offscreen canvas and converting that to an image, just render to the right place in the first place.
lambda 9y ago
CSS Houdini is a multi-vendor effort to make more aspects of CSS layout scriptable rather than all having to be specified ahead of time. https://ishoudinireadyyet.com/ https://ishoudinireadyyet.com/ This gives a much greater ability to iterate rapidly on new layout and styling details, polyfill for specifications that aren't widely implemented yet, and hook into some parts of the browser stack that you previously just had to use as is and trust that if you need a new feature, it would eventually be specified and/or implemented. I think this article does the best job of explaining the whole effort: https://www.smashingmagazine.com/2016/03/houdini-maybe-the-most-exciting-development-in-css-youve-never-heard-of/ https://www.smashingmagazine.com/2016/03/houdini-maybe-the-m...
- zawerf 9y ago
  Within the context of Houdini, the Paint API is less weird to me now. There are so many warts in CSS that I really wish I could customize. For example if I wanted to add a outside-aligned instead of center-aligned stroke to text, you can only accomplish it with lots of hacks: https://css-tricks.com/text-stroke-stuck-middle/ https://css-tricks.com/text-stroke-stuck-middle/ https://css-tricks.com/adding-stroke-to-web-text/ https://css-tricks.com/adding-stroke-to-web-text/. Using pseudoelements hidden behind, a circle of text-shadows, etc. I wonder if there's anything in the Houdini project that will let me fix this. This paint api is useless to me since it doesn't give me the original contents of the dom being styled (so I would need to redraw the text, style it and layout it on my own). The solution I ended up with is using svg filters: https://www.smashingmagazine.com/2015/05/why-the-svg-filter-is-awesome/ https://www.smashingmagazine.com/2015/05/why-the-svg-filter-.... But a unified solution to customizing CSS without needing to call it a hack would be nice.
bfgeek 9y ago
There are a few extra performance tricks we can do behind the scenes here. - Chrome's implementation won't actually perform a raster at this stage, instead we'll raster later on a background thread. toDataUrl, etc will raster. - We'll only invoke the paint method for things which we actually need to paint. E.g. if you have a long list, we won't invoke the method for things that are outside the paint window (things off-screen). - We'll have the ability to add a bunch of caching later on. From memory the servo folks in their experimental implementation actually speculatively generated a bunch of images ahead of time. - We are actively investigating moving this to a background thread. So even if your main thread is janked, an animation which triggers a paint worklet, will still run at 60fps. edit - formatting.

by zawerf 9y ago

zitterbewegung 9y ago

Embrace , extend and extinguish. Either that or developer ergonomics . Most likely the latter.

zawerf 9y ago
Developer ergonomics is good. I still remember days where you had to use images for shadows and round corners. Now it's just one line of CSS. But here it doesn't feel very ergonomic. You still need to write that JS code! Reading into it some more I think the only benefit it adds is state management (rerender on parameter change) but I don't really don't want/need CSS doing that for me.

untog 9y ago

It says that it'll re-run the code on resize, which is a lot easier than using a canvas manually then listening for window.onresize or something. And I suppose supplying the parameters in CSS instead of via a separate JS call is nice? Also, the mention of rendering off-thread in the future is pretty great, and not possible with current methods.

vertex-four 9y ago

I believe this could avoid at least one copy of the canvas's buffer from the graphics card to the CPU and back again - which might be useful for animation performance? Also, yeah, it's a more "obvious" way of doing this - instead of rendering to an offscreen canvas and converting that to an image, just render to the right place in the first place.

lambda 9y ago

CSS Houdini is a multi-vendor effort to make more aspects of CSS layout scriptable rather than all having to be specified ahead of time. https://ishoudinireadyyet.com/ https://ishoudinireadyyet.com/ This gives a much greater ability to iterate rapidly on new layout and styling details, polyfill for specifications that aren't widely implemented yet, and hook into some parts of the browser stack that you previously just had to use as is and trust that if you need a new feature, it would eventually be specified and/or implemented. I think this article does the best job of explaining the whole effort: https://www.smashingmagazine.com/2016/03/houdini-maybe-the-most-exciting-development-in-css-youve-never-heard-of/ https://www.smashingmagazine.com/2016/03/houdini-maybe-the-m...

zawerf 9y ago
Within the context of Houdini, the Paint API is less weird to me now. There are so many warts in CSS that I really wish I could customize. For example if I wanted to add a outside-aligned instead of center-aligned stroke to text, you can only accomplish it with lots of hacks: https://css-tricks.com/text-stroke-stuck-middle/ https://css-tricks.com/text-stroke-stuck-middle/ https://css-tricks.com/adding-stroke-to-web-text/ https://css-tricks.com/adding-stroke-to-web-text/. Using pseudoelements hidden behind, a circle of text-shadows, etc. I wonder if there's anything in the Houdini project that will let me fix this. This paint api is useless to me since it doesn't give me the original contents of the dom being styled (so I would need to redraw the text, style it and layout it on my own). The solution I ended up with is using svg filters: https://www.smashingmagazine.com/2015/05/why-the-svg-filter-is-awesome/ https://www.smashingmagazine.com/2015/05/why-the-svg-filter-.... But a unified solution to customizing CSS without needing to call it a hack would be nice.

bfgeek 9y ago

There are a few extra performance tricks we can do behind the scenes here. - Chrome's implementation won't actually perform a raster at this stage, instead we'll raster later on a background thread. toDataUrl, etc will raster. - We'll only invoke the paint method for things which we actually need to paint. E.g. if you have a long list, we won't invoke the method for things that are outside the paint window (things off-screen). - We'll have the ability to add a bunch of caching later on. From memory the servo folks in their experimental implementation actually speculatively generated a bunch of images ahead of time. - We are actively investigating moving this to a background thread. So even if your main thread is janked, an animation which triggers a paint worklet, will still run at 60fps. edit - formatting.