W3C home > Mailing lists > Public > public-houdini@w3.org > June 2015

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

From: Ian Kilpatrick <ikilpatrick@chromium.org>
Date: Sat, 27 Jun 2015 09:54:38 +1000
Message-ID: <CAJL3UpSsnNPbo7a-0BTDG3TCvKoAHWubbdP823-zxwumONM07g@mail.gmail.com>
To: François REMY <francois.remy.dev@outlook.com>
Cc: public-houdini@w3.org
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

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.
Received on Friday, 26 June 2015 23:55:07 UTC

This archive was generated by hypermail 2.3.1 : Friday, 26 June 2015 23:55:09 UTC