[css-paint-api] Are PaintWorkletGlobalScopes allowed to go away?

[bzbarsky]

https://drafts.css-houdini.org/worklets/#lifetime-of-the-worklet says:

The lifetime of a WorkletGlobalScope should be defined by subsequent specifications which inherit from WorkletGlobalScope.

but the Paint API draft doesn't define the lifetime of PaintWorkletGlobalScope objects. In particular, it's not clear whether a UA is allowed/required/forbidden to kill them off after executing some script in them (losing whatever global state the script might have stored).

[css-meeting-bot]

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.

The full IRC log of that discussion

<TabAtkins> Topic: Check with folks that we are fine with PWGS going away
<TabAtkins> github: https://github.com//issues/470
<nainar> s/PWGS/PaintWorkletGlobalScope
<TabAtkins> iank_: In Worklets we say that the later specs should define the lifetime of the global scopes.
<TabAtkins> iank_: We didn'ta ctually do this for PaintWorklets.
<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.
<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.
<TabAtkins> smfr: Is there any ability in worklets to store state between invocations?
<TabAtkins> iank_: Kinda, technically, but you shouldn't.
<TabAtkins> smfr: Maybe there should be an explicit API on worklets to stash state?
<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?
<TabAtkins> iank_: OUr handling is tha tin th econstructor you can do pre-work and pass things in.
<TabAtkins> iank_: We have non-deterministic selection of a global scope during painting, within a single frame, to discourage that behavior.
<TabAtkins> smfr: So I think we might want to solve that later.
<TabAtkins> TabAtkins: Yeah.
<TabAtkins> iank_: So yeah, are we fine with pwgs getting killed whenever, and spun back up when needed?
<TabAtkins> iank_: Like on low-memory devices, or when backgrounded.
<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.
<TabAtkins> iank_: We haven't heard much need for state yet, but
<TabAtkins> iank_: We should solve it when people ask for it.
<TabAtkins> smfr: Can you not specify it as every invocation gets a new global scope?
<TabAtkins> iank_: We don't want to require that.
<TabAtkins> smfr: Like "act as"...
<TabAtkins> smfr: Sam Weinig says we're basing on current impl concerns, because creating global scopes is expensive today...
<TabAtkins> TabAtkins: Spec def *allows* doing that.
<TabAtkins> TabAtkins: (throwing away the scope on every single call)
<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.
<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.
<TabAtkins> smfr: Is expectation that authors will communicate via custom properties over rAF, etc.
<TabAtkins> iank_: Yes.
<TabAtkins> smfr: And if it's an expensive object graph, they have to figure out how to serialize it
<TabAtkins> TabAtkins: Yes. Until people are asking for it, then we'll solve that better.
<TabAtkins> iank_: Tab and I have discussed allowing a custom property to declare its type as an arraybuffer.
<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
<TabAtkins> iank_: You can store that on the class instance.
<TabAtkins> smfr: That works across globals?
<TabAtkins> iank_: No.
<TabAtkins> TabAtkins: So that runs into the "fill every global scope you can find" behavior that dholbert was saying.
<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
<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
<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
<TabAtkins> Rossen: That's crappy.
<TabAtkins> Rossen: Would be better to define this behavior in general, and let Audio override that.
<TabAtkins> TabAtkins: So the assumption is that most worklets will use this lifetime logic.
<TabAtkins> Rossen: Yes.
<TabAtkins> RESOLVED: Define in Worklets that by default, their global scopes can be killed arbitrarily; let AudioWorklet specifically override that.