(评论)
(comments)

原始链接: https://news.ycombinator.com/item?id=44101619

Hacker News 上的一篇讨论围绕 CSS Painting API 展开。90s_dev 分享了他们使用该 API 的项目,并提到了 rough-paint。pjmlp 指出它是 Google 的 Houdini 项目的一部分,并将其与旧版 IE 的 CSS 渲染扩展进行了比较。 核心争论在于,在已有 Canvas API 的情况下,CSS Painting API 是否必要。goranmoomin 质疑渲染过程中增加的 JavaScript 依赖以及潜在的性能影响。AgentME 解释说,Paint Worklets 能够在单独的线程中进行渲染,这与绑定到主线程的 Canvas API 不同。MortyWaves 质疑 Canvas 的主线程限制,并提出了 WebAssembly 等替代方案。yladiz 建议使用 OffscreenCanvas 作为替代方案。 90s_dev 将该 API 看作是对重写 draw() 函数的回归,就像在旧的 GUI 系统中一样。reverseblade2 分享了一个演示网站,该网站面临跨浏览器兼容性和性能问题。参与者讨论了该 API 的用例。c-smile 以绘制文本区域调整大小句柄为例,dwoldrich 分享了一个包含更多用例的链接。hyperhello 质疑在 Canvas.toDataURL() 存在的情况下是否需要该 API,但 90s_dev 强调了性能优势和 worklet 支持。esprehn 指出该 API 具有更好的缩放行为和灵活性。


原文
Hacker News new | past | comments | ask | show | jobs | submit login
CSS Painting API (developer.mozilla.org)
53 points by 90s_dev 1 day ago | hide | past | favorite | 24 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. :-(


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.



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.


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


Consider