Re: [css-houdini-drafts] [css-paint-api] Consider making Path2D the only way to render paths with PaintRenderingContext2D.

The CSS Working Group just discussed `Consider making Path2D the only way to render paths with PaintRenderingContext2D.`, and agreed to the following resolutions:

* `RESOLVED: No change`

<details><summary>The full IRC log of that discussion</summary>
&lt;nainar> Topic: Consider making Path2D the only way to render paths with PaintRenderingContext2D.<br>
&lt;nainar> Github: https://github.com/w3c/css-houdini-drafts/issues/348<br>
&lt;fantasai> iank_: This was brought up by a Mozilla engineer<br>
&lt;fantasai> nical: That would be me<br>
&lt;fantasai> nical: Idea is that the way we want to evolve our rendering code involves a lot of expensive preparation that goes into making path into something we can render efficiently under GPU<br>
&lt;fantasai> nical: If we can do as much caching as possible, the better<br>
&lt;fantasai> nical: In light of doing a new API, if we could privilege things that are easier to optimize, like things that are retained, it's better for us<br>
&lt;fantasai> nical: If we don't expect to need to invalidate custom paint stuff might not be that much of a problem<br>
&lt;fantasai> iank_: Proposal was to drop the lineTo APIs and stuff<br>
&lt;fantasai> nical: Force people to use path objects so we can cache them<br>
&lt;fantasai> dino: Cant' cache them between calls<br>
&lt;fantasai> dino: Not going to keep path object between calls<br>
&lt;fantasai> dino: ...<br>
&lt;fantasai> dino: When draw comes, have to build the path every frame anyway<br>
&lt;fantasai> nical: That wasn't my understanding, thought state was preserved<br>
&lt;fantasai> iank_: Can potentially cache things in class, but can't rely on that cache existing<br>
&lt;fantasai> iank_: Could do ... and use as a cache key<br>
&lt;fantasai> dino: At that point API doesn't matter<br>
&lt;fantasai> dino: You would have an implementation cache, is this path the same as I used last time? If so pull it out of the cache<br>
&lt;fantasai> nical: I have a preference for being explicit about when things expire from cachce<br>
&lt;fantasai> dino: There's no way to specify in the API whether your'e going to keep the path<br>
&lt;fantasai> dino: Don't know whether you will reuse the path, whether need to keep the path around<br>
&lt;fantasai> dino: Unless you use SVG for ...<br>
&lt;fantasai> nical: Thought class registered for paint would be stored between invalidations<br>
&lt;fantasai> nical: So if that's the case then the web author could store the path objects in there<br>
&lt;fantasai> nical: in that case, it's very easy for us to know when things should be flushed out of the cache<br>
&lt;fantasai> nical: because it's the lifetime of the object that dictates that<br>
&lt;fantasai> nical: Have pref towards doing this rather than heuristic<br>
&lt;fantasai> till: That would be the case for this. ?? pressure would ..<br>
&lt;fantasai> dbaron: GC would be too slow for that<br>
&lt;dbaron> s/would/may well/<br>
&lt;fantasai> iank_: Other reason why I prefer not to do that is that existing 2D Path libraries rely on the path to the APIs being on the context<br>
&lt;fantasai> iank_: A lot of them work fine with the paint API as is, wouldn't want to put a barrier in front of authors to use the paint API<br>
&lt;fantasai> dino: tesselation dependent on transformation<br>
&lt;fantasai> dino: Just caching paths would be good, but also want to know the scale, tesselation, etc.<br>
&lt;fantasai> dino: No reason to be so accurate if drawing at a tiny scale<br>
&lt;fantasai> nical: My specific impl goal doesn't worry about scale<br>
&lt;fantasai> dino: When you say store on the class, there's no API for storing<br>
&lt;fantasai> iank_: It's .foo<br>
&lt;fantasai> dino: If we were going to store the path, I think we'd have a specific API for "please store this path"<br>
&lt;fantasai> iank_: I think nical was saying that any new 2d path that's created, it's cached as long as there's a strong reference to it<br>
&lt;fantasai> till: Youd' have to say "I still want to use this object", if not it gets discareded?<br>
&lt;fantasai> till: As long as you say "use this thing from previous frame" then keep it<br>
&lt;fantasai> dino: You do know you've used it because you've drawn it<br>
&lt;fantasai> ...<br>
&lt;fantasai> dino: Coudl do this without being explicit<br>
&lt;fantasai> iank_: Could get pretty far with heuristics<br>
&lt;fantasai> till: But that is easier with path2d<br>
&lt;fantasai> iank_: We'd just build up the path again insternally and compare to previous paths<br>
&lt;fantasai> dino: Conclusion is implementations can go a long way down this path<br>
&lt;fantasai> ...<br>
&lt;fantasai> nical: Don't have a strong objection, just if we reboot an API, should do something easier to optimize<br>
&lt;fantasai> dino: Your request was to remove part of the API, ignoring why<br>
&lt;fantasai> dino: I'd say that's pretty strong feedback<br>
&lt;fantasai> dino: For actual reason, we think we could optimize paths without removing that API<br>
&lt;fantasai> RESOLVED: No change<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/css-houdini-drafts/issues/348#issuecomment-319326870 using your GitHub account

Received on Tuesday, 1 August 2017 10:02:14 UTC