Re: [css-houdini-drafts] [css-layout-api] Design to allow for more layout engine optimizations. (#898)

The Houdini Task Force just discussed `Design to allow more layout engine optimizations`, and agreed to the following:

* `RESOLVED: no change, engines are allowed to do analysis to optimize the invalidation logic`
* `RESOLVED: Republish Layout API once Ian makes the edits from previous resolution.`

<details><summary>The full IRC log of that discussion</summary>
&lt;TabAtkins> Topic: Design to allow more layout engine optimizations<br>
&lt;astearns> github: https://github.com/w3c/css-houdini-drafts/issues/898<br>
&lt;TabAtkins> iank_: Layout engines have a lot of optimizations for the inputs to layout<br>
&lt;TabAtkins> iank_: Gave one example in the issue that I think all UAs have today<br>
&lt;TabAtkins> iank_: % height descendant, if your height changes you have to lay out that subtree; if your height doesn't change you don't need to<br>
&lt;TabAtkins> iank_: While performing optiizations for layoutng, I realized it owuld be good for the layout api to get those optimizations too<br>
&lt;TabAtkins> iank_: We currently pass the layout() a bunch of information<br>
&lt;TabAtkins> iank_: It would be nice for the webdev to let us know which of these they actually use when generating the fragment<br>
&lt;TabAtkins> iank_: So if they only use the available sizes, and a % size changes, we don't need to re-call them.<br>
&lt;fremy> q+<br>
&lt;TabAtkins> iank_: Today we can't optimize that<br>
&lt;TabAtkins> iank_: emilio this morning had the same idea I had; could we just figure out when a dev reads a particular prop off the constraints?<br>
&lt;fremy> q- emilio's question is exactly what I was going to ask<br>
&lt;fremy> q0<br>
&lt;fremy> q-<br>
&lt;TabAtkins> iank_: Turns out not good enough. So we do need explicit dependencies expressed.<br>
&lt;TabAtkins> AmeliaBR: They might check that property, but then switch and read a different property for acutal use.<br>
&lt;TabAtkins> iank_: Right. You might read availableInlineSize, then switch to using % size if it's small enough.<br>
&lt;TabAtkins> dbaron: But you do still have a dependency then<br>
&lt;TabAtkins> emilio: I commented about that, yeah.<br>
&lt;TabAtkins> emilio: I thought the engine could be smart, but that's not enough. Yo uneed an allowlist, as your might branch off of something else to see which one you need.<br>
&lt;fremy> +1 to what dbaron just said<br>
&lt;TabAtkins> dbaron: If you have `if(A) { if(B) {...}}`, if you take the else, you ddon't have a dependency on B. You'll rerun layout when *A* changes, at which point you might be checking B, but before then you won't need to invalidate based on B<br>
&lt;TabAtkins> myles: The story dbaron just told sounds scary...<br>
&lt;TabAtkins> dbaron: I think it's less scary than making authors do it themselves<br>
&lt;TabAtkins> dbaron: If authors do it themselves, they'll make the same mistake Ian did, and not mark dependencies (and thus get broken layouts)<br>
&lt;TabAtkins> AmeliaBR: But that list of dependencies can change each time.<br>
&lt;Rossen_> q?<br>
&lt;TabAtkins> emilio: If we have an allowlist I"d like to not expose the values that aren't allowed. But if we're just doing dependencies, I'm fine with all.<br>
&lt;TabAtkins> proposed resolution: no change, engines are allowed to do analysis to optimize the invalidation logic<br>
&lt;TabAtkins> RESOLVED: no change, engines are allowed to do analysis to optimize the invalidation logic<br>
&lt;TabAtkins> dbaron: I think there should be a note in the spec about this<br>
&lt;TabAtkins> iank_: Definitely<br>
&lt;TabAtkins> Rossen_: Ian, can you repub this?<br>
&lt;TabAtkins> iank_: Yes.<br>
&lt;TabAtkins> RESOLVED: Republish Layout API once Ian makes the edits from previous resolution.<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/898#issuecomment-499968593 using your GitHub account

Received on Friday, 7 June 2019 17:21:11 UTC