Great news! I guess that may also mean billm's bug 1308039 [1] which tried to do painting during GC (which will be backed out soon [2] because of lots of breakage) may never get chance to land anymore, since this API means it is expected to run JS code during painting.
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1308039 [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1328423 - Xidorn On Fri, Jan 6, 2017, at 03:00 AM, Jet Villegas wrote: > 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 _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
