[css-paint-api] Unnecessary paint-valid flag?

[asajeffrey]

The css-paint-api spec includes a paint-valid flag https://drafts.css-houdini.org/css-paint-api/#paint-valid-flag.

This flag is maintained as global mutable state, and is set invalid by they style engine, and valid by the paint worklets. This produces the usual problems of shared mutable state in a concurrent implementation.

The flag's main purpose is to avoid re-drawing paint images when the properties have not changed, but this is already handled by step 10 of https://drafts.css-houdini.org/css-paint-api/#invoke-a-paint-callback:

At this stage the user agent may re-use an image from a previous invocation if paintSize, styleMap, inputArguments are equivalent to that previous invocation. If so let the image output be that cached image and abort all these steps.

Since user agents are allowed to reuse previous results, it looks like the paint-valid flag is no longer needed.

[asajeffrey]

This came up in discussion of #439 with @tschneidereit and @bfgeek.

[bfgeek]

So I think this section still has value, it might make sense to change this to being non-normative, and explaining how an engine with this type of invalidation could implement it.

Thoughts?

[css-meeting-bot]

The Working Group just discussed Make paint invalidation non-normative or something?.

The full IRC log of that discussion

<dael> Topic: Make paint invalidation non-normative or something?
<dael> github: https://github.com//issues/447
<dael> iank_: Pointed out by Alan Jeffrey that...basically we have a section of the paint spec that says how invalidation works.
<dael> iank_: If you have a paint validation and the style changes you have to make changes and you invalidate. It was pointed out you don't need that because you have the caching function. The caching is all the input are the same. So we could drop the whole paint invalidation section and rely on the caching and that engines can be cleverer.
<dael> iank_: Thoughts?
<dael> iank_: We could make this non-normative and say you can do validation this was or rely on caching step.
<dael> dbaron: I have a valgue memory when I looke d awhile ago I thought this section was more complex then it needed to be.
<dael> iank_: Maybe. I think I changed it since then where we moved the invalidation to individual pain functions. [reads]
<dael> iank_: WE could drop this and let the engines do smarter. Or make the whole section non-normative saying that engines can add incalidation.
<dael> shane: It would be much faster [missed]
<dael> Rossen: Leaning toward making it non-normative?
<dael> iank_: I'm fine with that. I think it should still be in the spec because I think engines will do that.
<dael> krit: Is there something we should add to ensure that everything is correct?
<dael> iank_: We did that.
<dael> smfr: The invalidation isn't exposed.
<dael> iank_: Yeah.
<dael> iank_: as a webkit engine impl your thoughts?
<dael> smfr: I don't think there's value to this section. Is there other text that spec when something becomes invalid?
<dael> iank_: No
<dael> smfr: You need that. You need to desc imputs that trigger
<dael> iank_: We've got that in the cache step. The paint size and similar.
<dael> Rossen: Objections to dropping section 2: paint invalidation ?
<dael> rESOLVED: drop section 2: paint invalidation