Re: [custom-paint] Replacing some of element()'s use-cases with Custom Paint

> On 6 Jun 2015, at 7:46 am, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> 
> Currently, the element() function
> <http://dev.w3.org/csswg/css-images-4/#element-notation> basically
> does three things:
> 
> 1. Duplicates an element in the tree, to use elsewhere in the document
> as an image. (The "thumbnail" use-case.)
> 
> 2. Lets you use an SVG paint server in CSS. (The "paint server" use-case.)
> 
> 3. Lets you create a JS-animated image, by referring to an
> out-of-document canvas.  (The "animated image" use-case.)
> 
> (There are a few other cases, but they're very similar to or devolve
> into one of these three.)
> 
> The third one has had problems for some time.  In particular, in the
> current API, there's no way to know when you should update the canvas,
> whether the image is on-screen, what dimensions the image is, etc.
> You just have to guess at all of this, producing a canvas of some
> guessed size and painting it constantly at some guessed interval
> (probably tied to rAF()).
> 
> Custom Paint is designed to do something very similar to this
> use-case, but in a way that resolves all of these problems.  At least
> one proposed syntax variant (a paint() function you can use as a CSS
> <image>) would have the same usability as element(), too.
> 
> I think it's reasonable to just declare that Custom Paint is going to
> solve this use-case much better than element() is currently, and
> remove this functionality from element().

That might be so, but I'd really like to make sure that custom
paint provides something as simple as element()/canvas(), in that
I can create a single bitmap ahead of time and have the browser
use it as a source for painting operations on multiple elements, and
have them automatically repaint when I update the bitmap.

You mention "trivial custom painters" below, but that's still
logic I have to write. It seems perfectly reasonable to have
an API that is ONLY a CSS image generator, and I've found it to be
useful in a lot of internal-to-Apple content.

So while Custom Paint will address all the use cases existing in the
universe, known or unknown, let's not forget that it is also ok to
provide a simple API for simple use cases. Otherwise we might as well
get also rid of background painting, border painting, etc.

>  element() has always been a
> weird name for this particular piece of functionality anyway; it was
> just a convenient and vaguely-appropriate place to put it.

That's definitely true. I think canvas() was a better name/place. IIRC,
in Shenzen the WG resolved to add canvas but you put it in element instead.

Dean

> 
> This also means we can remove the .elementSources map.  This was its
> primary reason for existing.  SVG paint servers can just be put into
> the document rather than held out-of-document in the map, and <img>
> and <video> can be handled through a trivial custom painter, or put
> into the doc off-screen.  This removes a good chunk of element()
> complexity without increasing the use-cases by more than a trivial
> amount (assuming we do Custom Paint right).
> 
> Thoughts?
> 
> ~TJ
>

Received on Thursday, 25 June 2015 22:08:52 UTC