Spec: https://drafts.css-houdini.org/css-paint-api/
Summary: The CSS Paint API is the first of several Web Rendering proposals from the CSS Houdini Task Force. The CSS Paint API allows Web authors to define and register a custom Paint method to be executed by the Layout engine as other elements are rendered. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1302328 Link to standard: https://drafts.css-houdini.org/css-paint-api/ Platform coverage: Android, Desktop Estimated or target release: TBD Preference behind which this will be implemented: TBD DevTools bug: TBD Tests - TBD Implementation Details: CSS Paint API depends on the implementation of the following features: CSS Houdini Properties & Values - https://bugzilla.mozilla.org/ show_bug.cgi?id=1273706 Houdini "Worklets" - https://bugzilla.mozilla.org/show_bug.cgi?id=1290021 The planned implementation in Gecko builds upon the HTML5 Canvas2D API to provide the rendering surface for CSS Paint. Risks: The experimental implementation has progressed enough to warrant this public Intent to Implement. However, significant risks will need to be mitigated by careful design and execution if these features are to pass the experimental stage and ship in Firefox, including: 1. Use Cases. It's not clear that the use cases proposed in the specification warrant the additional Rendering System complexity. Apart from conical gradients, we haven't seen many author requests for the other use cases. If the existing Canvas2D feature set is lacking, what are the compelling use cases and maximally useful API for such use cases? It's not clear that the proposed Canvas2D-based API is desirable over a different API design (eg., WebGL) if most use cases need to directly manipulate pixels. 2. Rendering Performance. The planned Canvas2D backing store approach may be too slow for real-world usage of the API. In the future, we may replace the Canvas2D approach to have the custom paint methods create Layout (displayList) nodes for direct rendering by the Layout engine, bypassing the need for a Canvas2D backing store. It's worth noting that the Paint API isn't directly compatible with existing displayList nodes (e.g., support for raw paths, funny shapes, & pixel manipulation.) There may also be other performance issues that arise with the API's usage in combination with existing CSS features (e.g., CSS Masking, Filters, etc.) The displayList vs. canvas bitmap implementation would probably look a good bit different in WebRender. It's also worth noting that multiple implementations shipping a bitmap-based version can create dependencies that prevent us from switching to a faster alternative version in the future. 3. Integration with Gecko Architecture. The Quantum Project < https://wiki.mozilla.org/Quantum> is a major overhaul of the Firefox Rendering Engine. Implementing the CSS Paint API while that effort is in progress may add significant impedance. However, a counter-argument is that we should design Quantum to allow for such extensibility in the future. Duplication of work ( writing code that would need to be rewritten for Quantum ) is not desirable and should be avoided. For WebRender/Quantum, we could initially push this through the same path that SVG will go through (which will be rasterized on the CPU and then cached in a GPU texture atlas). It does seem like Houdini Paint could reduce the amount of acceleration we can do on the GPU (at least in the short term), but we won't be any worse off than other browsers in that regard. 4. Dependency on incomplete implementations/specifications. The dependency creates a chicken/egg scenario where we can't sufficiently evaluate the dependent specifications (e.g, Worklets, and Properties & Values) without also implementing an initial key use case (e.g., CSS Paint or Worklets for Web Audio.) This is somewhat mitigated by getting the implementation far enough along to formulate informed opinions on all the specifications. The Houdini Task Force is meeting next week in Seattle to discuss this and other specifications. _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
