- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Mon, 09 Apr 2018 10:25:24 +0000
- To: public-houdini-archive@w3.org
The Working Group just discussed `Lifetime for passed in arguments to layout, intrinsicSizes`, and agreed to the following resolutions: * `RESOLVED: the lifetime of inputs and collections is the same as the policy for worklet swapping` <details><summary>The full IRC log of that discussion</summary> <dael> Topic: Lifetime for passed in arguments to layout, intrinsicSizes<br> <dael> github: https://github.com/w3c/css-houdini-drafts/issues/745<br> <dael> iank_: We've got a bunch of objecs passed in. layoutChildren most itneresting. You may want something similar as layout instance where you get passed the same child every time.<br> <dael> Rossen: Or I can stash all the children and look them up<br> <dael> iank_: But if you pass in new children you can't.<br> <dael> dbaron: If you have this cache you need to define child ID carefully. If a child changes display-type do you get a different child, if it changes overflow do you get a different child.<br> <dael> dbaron: Is this like, do you have a different box type<br> <dael> iank_: Yes.<br> <dael> dbaron: Do you have a different box type isn't interop. bllock with and without scrollbars is different for Gecko.<br> <dael> ??: Does thecalculation matter on times when the child would change?<br> <dbaron> s/??/biesi/<br> <dbaron> s/biesi/cbiesinger/<br> <dael> iank_: The reason you want to use this cache is similar to the gird example where from this currently layout you want to calculate something based on the child's style.<br> <dael> cbiesinger: You would need to store the old value for that case<br> <dbaron> (cbiesinger was asking about the risk of a developer caching something that might not be valid after certain types of changes)<br> <dael> iank_: Right, but string comparision is cheaper then regen the object.<br> <dael> smfr: Layout child isn't exposed to different custom layout, right?<br> <dael> iank_: Right. THere's like 2 or 3 polocies here. Like the others we can regen each time. There's also a question about passing in same style map. We can start with regen each argument call and try and loosen.<br> <dael> smfr: In the JS can't you say it's read only?<br> <dael> iank_: Yes, but you can use layout child as a key still.<br> <dael> smfr: [missed]<br> <dael> iank_: Yes but this instance.<br> <dael> smfr: Pure read only is good. caching should be like an API. You want the perf guar that when yourun the code it'll go fast.<br> <dael> iank_: Cache have structure which is expensive.<br> <dael> iank_: We've made it faster, but it's not as quick.<br> <dael> majidvp: You only have to clone the structure when moving global scope.<br> <dael> iank_: The object will always be alive. So you ahve to call every time<br> <dael> majidvp: YOu need to serialize and then destructu<br> <dael> iank_: You have to serialize it out.<br> <dael> majidvp: Cache is strictly there to help you cache the structure.<br> <dael> iank_: If you go back to you can twiddle things on the object then you can stay there.<br> <dael> iank_: That's why I'd like to keep this object for stashing state.<br> <dael> smfr: Consistant but slow reserialization or a faster but hiccupy. I'd prefer the consistent approach.<br> <dael> iank_: If we regent each time it depends on number of children by it can be much slower.<br> <dael> iank_: I can benchmark, but my hunch is creating them each time rather then trying to cache it'll be a substantial difference.<br> <dael> smfr: You'll pay that in the long rame, though.<br> <dael> iank_: Yeah. But if you have something deeply bad you'll get it.<br> <dael> smfr: I think these APIs are problematic if they're not perf guar. If the author wants to do a good job and they're penilized everything 39th frame...<br> <dael> iank_: That's why you may want to keep the instance around so when scope switching you get the gaur. You've got an instance tied.<br> <dael> smfr: 2 instances will have the author really confused.<br> <dael> iank_: If the author never recalcs from the complex thing then you get [missed]<br> <dael> iank_: What do you want to do?<br> <dael> Rossen: Since you're the furthest in impl, what do we know so far in terms of requirements, expectations, and patterns.<br> <dael> iank_: We've got more people using it. We might give this to people and see if they run into issues.<br> <dael> Rossen: To smfr point and I sympathize, it should be fine to allow custom layout or paint to pass different information between passes.<br> <dael> Rossen: WE have a few issues. One of defining what the lifetime of the boxes are if this will tie in lifetime of other objects. THis is the point dbaron was making. You'll regenerate boxes different times then Gecko. That's not to say the instances we keep should have same lifetime. That can be based on something else like a display prop changing.<br> <dael> Rossen: That will get us into trouble as custom prop are more common so we'll again be in a tight place for lifetime.<br> <dael> Rossen: Other option is to say we have a policy that you need to redo everything at a certain time and that's a fine expectation.<br> <dael> Rossen: I prefer to be as agressive as possible on cleaning up and resetting. If the explicit stash is needed, define that, give that API, and let people stash something besides custom properties.<br> <RRSAgent> logging to https://www.w3.org/2018/04/09-houdini-irc<br> <dael> Rossen: We don't penelize people running on an awesome device. If we do have to have penalties we have information about what we need to keep. Seems like the best compromise on both sides of the fence.<br> <dael> iank_: We can tentatively do that for now and see what happens.<br> <dael> Rossen: If we want a resolution, not just a tentative what does it mean.<br> <dael> Rossen: We can introduce and explicit cache which re-writes cache<br> <dael> iank_: I don't think we want that yet.<br> <dael> Rossen: Even better.<br> <dael> iank_: For now instances and layout children get nuked when we switch global scopes<br> <dael> smfr: why not new children and isntance on invokation?<br> <dael> iank_: I'm worried about performance. Invoking a constructor is a few ms each time.<br> <dael> iank_: Let's start with we nuke everything when switching global scopes.<br> <dael> Rossen: Only thing we're adding is that input are also new instances.<br> <dael> Rossen: smfr ?<br> <dael> smfr: I'd prefer the super clean APIs where everything is done internally. Authors won't be surprised. If we do anything else they will get confused.<br> <dael> iank_: Should we see if authors will get confused?<br> <dael> smfr: If you can find some that are fresh.<br> <dael> iank_: We can do an origin question and find out.<br> <dael> Rossen: Not per call?<br> <dael> iank_: Yep.<br> <dael> Rossen: Objections to the lifetime of inputs and collections is the same as the policy for worklet swapping?<br> <dael> RESOLVED: the lifetime of inputs and collections is the same as the policy for 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/745#issuecomment-379706347 using your GitHub account
Received on Monday, 9 April 2018 10:25:25 UTC