Re: [css-houdini-drafts] [css-layout-api] Lifetime for instance of layout class.

The Working Group just discussed `Lifetime policy for passed in objects, e.g. LayoutChild`, and agreed to the following resolutions:

* `RESOLVED: The instance is tied to the same policy as worklet swapping.`

<details><summary>The full IRC log of that discussion</summary>
&lt;dael> Topic: Lifetime policy for passed in objects, e.g. LayoutChild<br>
&lt;dael> github: https://github.com/w3c/css-houdini-drafts/issues/746<br>
&lt;dael> iank_: For a box with a layout instance it's tied to a lifetime of boxes. The box drops out of the tree.<br>
&lt;dael> dbaron: This is the thing in the spec with a bunch of prowse about these get chaced by worklet and only cache is distroyed when box is dropped.<br>
&lt;dbaron> s/prowse/prose/<br>
&lt;dbaron> s/chaced/cached/<br>
&lt;dael> iank_: Yes. For example in our impl if we have 2 layout level scopes both will have one instance. It lets you have expensive cached calcualtion = something<br>
&lt;dael> iank_: We could have a policy where we kill it every 1000 times and regenerate, but there's a value to keep them<br>
&lt;dael> dbaron: There's the same worry about layout global scopes...so if you're keeping worklet level every 1000 you'll get something after relayout.<br>
&lt;dael> iank_: Yes. Is the global scope switching enough? Or do we want something more expensive<br>
&lt;dael> Rossen: Will you be allowed to reuse the worklet?<br>
&lt;dael> iank_: Yes. If you've got 2 boxes that run the same worklet, each will have its own instance.<br>
&lt;dael> iank_: A good example is 3. In our impl we do specific caching on internals, you could do that here for layout reasons.<br>
&lt;dael> fremy: Didn't we discussion a shared cache across worklets?<br>
&lt;dael> iank_: We did....<br>
&lt;dael> Rossen: If what you want to share is the results...unless the read only cache is read/write that's okay. but then you will be producing a lot of generating. If it's read-only it has to be communiable. But that's a good first step.<br>
&lt;dael> Rossen: In more complex layouts you have a ton of layout information you want to preserve between passes.<br>
&lt;dael> iank_: It's regernatable.<br>
&lt;dael> iank_: That's why I prefer an instance that does live across many frames. Question is do we nuke this instance.<br>
&lt;dael> Rossen: If I understnad, the only cost we will have when we nuke the instance or somehow remove it, it's perf.<br>
&lt;dael> iank_: Yes. Should be cheap from our PoV to regen the state. That's the big question. This is somewhat edgecasey, but every minute need to recreate.<br>
&lt;dael> Rossen: When we discussed 2+ worklets and all the costs, we did this for many reasons. Why should we change those for this case?  I would say for now carry the policy.<br>
&lt;dael> iank_: Policy doesn't require you to kill, just switch.<br>
&lt;dael> iank_: We're not wiping out a state we just have bad state.<br>
&lt;dael> Rossen: My hope is anything you do that depends on gloabl state should be discouraged. If we have an explicit reason we will care information on your behalf, that's fine. I don't see why this should be special unless we run into memory pressure. In that case you have to be prepared to regen.<br>
&lt;dael> iank_: Lifetime of the box unless UA needs to regen.<br>
&lt;dael> iank_: I'm also fine with that or jut adding something preemtively.<br>
&lt;dael> Rossen: If the stash will be not needed can't we make it explicit?<br>
&lt;dael> iank_: It is.<br>
&lt;dael> Rossen: But if you have a stach that's necessary...if they have a stash where these are the things I spent 40 minutes calculating the perfect size and I want to preserve it...I can have all kinds of other garbage you shouldn't retain.<br>
&lt;dael> iank_: But people that have cached, we can always be there later.<br>
&lt;dael> iank_: Fine with tying one time to the box?<br>
&lt;dael> TabAtkins: No worse then globals<br>
&lt;dael> Rossen: What is lifetime of the box?<br>
&lt;dael> s/one time/lifetime<br>
&lt;dael> emilio: Blink only dsitroys tree when display changes. So if you change display any parent box will be dropped.<br>
&lt;dael> iank_: Might be a reason why we nuke the instance every 1000 times. You drop the box on resizes?<br>
&lt;dael> Rossen: Yeah.<br>
&lt;dael> iank_: May be why we drop periodically<br>
&lt;dael> iank_: Reuse the instance no more then 1000 times as the policy?<br>
&lt;dael> dbaron: How can you reuse more?<br>
&lt;dael> iank_: Gloabl scopes changes, but don't tear down. Here we're saying you reached the max and we're going to ear it down and rebuild<br>
&lt;dael> dbaron: Might be good to have a sentence or two with explaining the algo.<br>
&lt;dael> iank_: Yeah.<br>
&lt;dael> dbaron: As a reader if there had been 2 sentences explaining the algo I wouldn't have had to read the alog.<br>
&lt;dbaron> s/alog/algorithm/<br>
&lt;dael> iank_: Reuse the layout instance no more than 1000 times, after that you must regin.<br>
&lt;dael> Rossen: Or drop whenever you switch worklets.<br>
&lt;surma> s/regin/regenerate/<br>
&lt;dael> Rossen: Other suggestions? prop: The instance is tied to the same policy as worklet swapping.<br>
&lt;dael> iank_: Not explicitly.<br>
&lt;dael> Rossen: If you switch event 1000 times you get it 1000 times.<br>
&lt;dael> iank_: I'm fine with that.<br>
&lt;dael> Rossen: Let's see how it goes. If perf is decremented then let's discuss it. It's always easier to relax later.<br>
&lt;dael> Rossen: Objections?<br>
&lt;dael> RESOLVED: The instance is tied to the same policy as worklet swapping.<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/746#issuecomment-379700925 using your GitHub account

Received on Monday, 9 April 2018 10:03:57 UTC