Re: [custom-paint] First iteration of level 1 spec.

Hi François,

Thanks for reviewing!

On Sat, Jun 27, 2015 at 8:09 AM, François REMY <
francois.remy.dev@outlook.com> wrote:

> > Greg, Rossen, Shane, Tab & I sat down over VC today
> > and did a read-through of any issues initially that might
> > arise.
> >
> > Please have a read and let us know of any feedback on
> > the API design and potential issues.
> >
> > http://dev.w3.org/houdini/css-paint-api/
>
> LGTM except I don't see any issue mentioning that resources like images or
> videos might be required to draw the painting. How can the handler
> communicate that the rendering isn't done yet and invalidates himself asap
> (once the image loaded, for instance), or aren't we going to support this
> at all?
>

You're right that this doesn't cover the image source use case in the spec
at the moment (and that this is important!)

I think this should be solved by a Typed Style OM, instead of the string
based style objects that we have at the moment.

For example, currently we have:
var computedStyle = /* from getComputedStyle or inputProperties */;
var justAString = computedStyle['background-image'];

This is bad as it contains no information that the engine has internally,
such as the natural width/height, if the image is loaded yet, etc.

I think we should expose this information to authors via a Typed Style OM.

Having this the Typed Image could be a CanvasImageSource and directly
written into the canvas.
ctx.drawImage(typedUrlImageThatIsLoaded, 0, 0);

Additionally, one of the advantages of CSS Properties and Values API Level
1 is that custom properties can now have types. This means that they can be
potentially exposed in a Typed OM as well.

That said this is really only for the image resource use case. Video
sources aren't currently exposed by CSS.


> I guess animated paintings are supported by marking the painting dependent
> of a "--painting-time" custom property which can be continuously updated
> from 0 to 100% by an animation. That does not require a specific api,
> allowing to keep things simple by default.
>

Yup thats correct. The nice thing about being an explicit stage in the
pipeline, is that we can rely on CSS Transitions, Web Animations, etc to
trigger a paint invalidation.

Again having a type on '--painting-time' means that the animation engine
knows how to interpolate between two values, set with transitions for
example.

I'm slightly in favor of reusing last frame in case a painting doesn't
> finish on time, so that at the very least a painting that misses one frame
> doesn't flash empty. If the target geometry has changed, then the image is
> just used as-is and transparent sections may appear where there was
> previously no rendering.
>

Thats a good point. I'm not sure what the right answer here is. I'll make a
note to discuss it F2F.