Re: [css-paint-api] Spec feedback

On Friday 2015-08-21 17:51 -0400, Benoit Girard wrote:
> 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.

I'd also add that I'm not sure that putting "must"-level conformance
requirements on Web content is useful.  It might be more useful to
say that having paint callbacks not be idempotent will produce
implementation-dependent behavior.  (Then again, it may also be
useful for testing.)

> 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.

It also seems like the spec should say more about the initial state
of the canvas in general.  It currently says only:
  # Implicitly this means that there is no stored data, or state on
  # the rendering context. For example you can’t setup a clip on the
  # context, and expect the same clip to be applied next time the
  # function is called.
whereas it seems like the initial state of the canvas ought to be
defined.

> 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?

I think the intent might be that PaintGlobalScope is a separate
something (realm?).  But I think that is meant to imply that there's
shared state between all the callbacks, which I'm not sure is good
(as you point out in (l)); it seems like it would constrain
callbacks from being run on different threads.

-David

-- 
𝄞   L. David Baron                         http://dbaron.org/   𝄂
𝄢   Mozilla                          https://www.mozilla.org/   𝄂
             Before I built a wall I'd ask to know
             What I was walling in or walling out,
             And to whom I was like to give offense.
               - Robert Frost, Mending Wall (1914)