[css-paint-api] Spec feedback

Hello all,

I made a brain dump of some potential issues I saw with the spec in hope to
help improve it. It's not listed in any particular order. There's been some
edit to the spec since I wrote this so perhaps some of these are out of
date. I focused on what restrictions might be imposed on the
rendering/rasterization phase of the user agent by implementing this spec.

a) The spec says 'paint callbacks should be idempotent'. Should this
feature allow for, say time based, animated properties? Is Date accessible
from the PaintGlobalScope? This would interact with implementations such as
immediate tile based painting where depending on the time API used it could
drift between the first tile paint and the last. Currently the 'Paint
Invalidation' section doesn't allow this but it might be a concern for
forward compatibility.

b) What happens if you registerPaint more than once with the given name?
Does it replace or do the callbacks stack and if so the behavior should be
specified.

c) I agree with issue #5, better partial-invalidation (from both side) I
think would be valuable. With immediate tile based rendering it would
useful for the user agent to tell large paint callback that it's only
interested in updating a subrect.

d) What assumptions can the paint callback make about the canvas and what
assumptions should it explicitly avoid making? For instance when doing
immediate tile based rendering, say 256^2 tiles, of a large fragment say
1024^2 the user agent may want to fire 4 callbacks for each tile. Can the
paintCallback make any assumptions about the canvas width/height,
transformation and clip? This is closely related to partial-invalidation.

e) Reading the CSS properties as DOMString doesn't seem ideal. Imagine
--my-property-options: <transform-list> | ... where you could transform the
results in 2.5D, you would have to re-implement the CSS parsing for
<transform-list>.

f) Related to Issue #7, a contextType can be provided but PaintCallback
param 1 is of type CanvasRenderingContext2d.

g) What should the paint callback do when it encounters an error parsing
the dependent css properties? The spec could say that if a paint callback
throws a javascript exception with an error message then the user agent can
report it. I'd imagine it would be useful if the paint callback can easily
bubble up to the developer tools a parsing error with a particular
dependent CSS property similar to how dev tools currently highlight errors
like 'width: SomeText'.

h) Similarly what should the user agent do if there was an exception thrown
during the paint callback unrelated to parsing. I'd imagine that the user
agent can simply present the rendering context with whichever operations
were completed before the error.

i) Naming nit: Shouldn't hookID be called hookHandle or
cssPaintRequestHandle?

j) PaintCallback is a callback. It looks like it would have access to the
outer scopes. Web workers specify a script URL where it's clear that they
don't have access to the outer scope. Should it match web workers?

k) Should the CanvasRenderingContext2d be considered write-only, similar to
'tainted' canvas. This makes both immediate rendering simpler. It also
makes deferred rendering simpler because the user agent might be equipped
to issue the rendering commands in that thread/process so it couldn't
easily provide the pixels.

l) The PaintCallback can hold a reference to the CanvasRenderingContext2d
which can cause some headaches for the implementation. For example the
canvas buffer could be a reference into temporarily mapped GPU memory where
the user agent can't hold a reference. What happens if the previous
rendering context is accessed from a future invocation PaintCallback by
maintaining a reference? I see that getImageData is now a no-op. The spec
currently says that the state is not transferred to the rendering context
on the next paintcallback but it might be a different context. What happens
to the context if you keep a strong reference to it. Can the PaintCallback
maintain state at all?

m) Are each PaintGlobalScope independent? Can information be shared between
PaintCallbacks in any way like postMessage? This can have implication for
the invalidation.

-Benoit