- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 09 Nov 2017 19:52:26 +0000
- To: public-houdini-archive@w3.org
The Working Group just discussed `Check with folks that we are fine with PWGS going away`, and agreed to the following resolutions: * `RESOLVED: Define in Worklets that by default, their global scopes can be killed arbitrarily; let AudioWorklet specifically override that.` <details><summary>The full IRC log of that discussion</summary> <TabAtkins> Topic: Check with folks that we are fine with PWGS going away<br> <TabAtkins> github: https://github.com/w3c/css-houdini-drafts/issues/470<br> <nainar> s/PWGS/PaintWorkletGlobalScope<br> <TabAtkins> iank_: In Worklets we say that the later specs should define the lifetime of the global scopes.<br> <TabAtkins> iank_: We didn'ta ctually do this for PaintWorklets.<br> <TabAtkins> iank_: Was out intention to be able to kill the global scopes, such as when a page is backgrounded, but not explicitly require that.<br> <TabAtkins> iank_: So proposal is to say you're allowed to kill them whenever, and give some examples of when UAs may decide to do it.<br> <TabAtkins> smfr: Is there any ability in worklets to store state between invocations?<br> <TabAtkins> iank_: Kinda, technically, but you shouldn't.<br> <TabAtkins> smfr: Maybe there should be an explicit API on worklets to stash state?<br> <TabAtkins> iank_: Problem is that if you have multiple threads, like servo's impl, do you expect that to be synchronized within a frame, or only visible next frame?<br> <TabAtkins> iank_: OUr handling is tha tin th econstructor you can do pre-work and pass things in.<br> <TabAtkins> iank_: We have non-deterministic selection of a global scope during painting, within a single frame, to discourage that behavior.<br> <TabAtkins> smfr: So I think we might want to solve that later.<br> <TabAtkins> TabAtkins: Yeah.<br> <TabAtkins> iank_: So yeah, are we fine with pwgs getting killed whenever, and spun back up when needed?<br> <TabAtkins> iank_: Like on low-memory devices, or when backgrounded.<br> <TabAtkins> surma: I think we def should, we have people trying to rely on the global scope persisting, and that hurts our ability to prioritize.<br> <TabAtkins> iank_: We haven't heard much need for state yet, but<br> <TabAtkins> iank_: We should solve it when people ask for it.<br> <TabAtkins> smfr: Can you not specify it as every invocation gets a new global scope?<br> <TabAtkins> iank_: We don't want to require that.<br> <TabAtkins> smfr: Like "act as"...<br> <TabAtkins> smfr: Sam Weinig says we're basing on current impl concerns, because creating global scopes is expensive today...<br> <TabAtkins> TabAtkins: Spec def *allows* doing that.<br> <TabAtkins> TabAtkins: (throwing away the scope on every single call)<br> <TabAtkins> dholbert: So spec currently allows authors to try and rely on chrome bheavior by filling every scope with the precomputed data... webkit would then be slow.<br> <TabAtkins> TabAtkins: That case assumes using the data as immutable after computation. Mutation still doesn't work. You can handle precomputation in the constructor today.<br> <TabAtkins> smfr: Is expectation that authors will communicate via custom properties over rAF, etc.<br> <TabAtkins> iank_: Yes.<br> <TabAtkins> smfr: And if it's an expensive object graph, they have to figure out how to serialize it<br> <TabAtkins> TabAtkins: Yes. Until people are asking for it, then we'll solve that better.<br> <TabAtkins> iank_: Tab and I have discussed allowing a custom property to declare its type as an arraybuffer.<br> <TabAtkins> smfr: If your expensive data needs to know the box size, you need to do the computation in the worklet over and over, even if the box size doesn't change<br> <TabAtkins> iank_: You can store that on the class instance.<br> <TabAtkins> smfr: That works across globals?<br> <TabAtkins> iank_: No.<br> <TabAtkins> TabAtkins: So that runs into the "fill every global scope you can find" behavior that dholbert was saying.<br> <TabAtkins> TabAtkins: Ian and I talked about this - probably want to eventually define some sort of data store that can recieve the same invalidation logic that is used for invoking the callbacks themselves<br> <TabAtkins> TabAtkins: So you can compute that data and pass it in, and get a chance to recompute it only when the box size changes<br> <TabAtkins> Rossen: Currentlyw e have no lifetime spec on the worklet globa scope because of Audio, and so we have to specify lifeteime in the derived classes<br> <TabAtkins> Rossen: That's crappy.<br> <TabAtkins> Rossen: Would be better to define this behavior in general, and let Audio override that.<br> <TabAtkins> TabAtkins: So the assumption is that most worklets will use this lifetime logic.<br> <TabAtkins> Rossen: Yes.<br> <TabAtkins> RESOLVED: Define in Worklets that by default, their global scopes can be killed arbitrarily; let AudioWorklet specifically override that.<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/470#issuecomment-343271875 using your GitHub account
Received on Thursday, 9 November 2017 19:52:29 UTC