W3C home > Mailing lists > Public > www-style@w3.org > July 2012

Re: [css4-images] element() and compositing layers

From: Simon Fraser <smfr@me.com>
Date: Fri, 27 Jul 2012 18:32:15 -0700
Cc: www-style list <www-style@w3.org>
Message-id: <1A2D0430-16B8-4EEA-8478-2C3C5E215F5E@me.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
On Jul 27, 2012, at 4:13 PM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote:

> This question is more-or-less directed toward the Moz implementors of
> -moz-element().
> I presume that you have a similar hardware compositing model to us at
> WebKit, where some elements establish compositing layers, but not all
> of them - each node in the compositing tree may contain multiple
> descendants of the node-establisher.
> What do you do when a -moz-element() references one of these elements
> that aren't the root of a compositing-tree layer?  I can see a few
> options:
> 1. Split apart the layer so that the referenced element establishes a
> layer.  (This seems to require either making it a stacking context, or
> doing some more advanced trickery.)
> 2. Do a paint with the existing layer, but do an ancestry check on
> each element, skipping painting of those that aren't descendants of
> the referenced layer.
> 3. Draw element() images with a different path than what's used for
> normal page rendering.
> 4. Something else?

In WebKit at least, I think we'd have to do a software paint for element()
content, so it doesn't really matter that parts are independently composited.

This means that we would not render 3d transforms in element(), and 
video playback would perform poorly.

Spec-wise, the more interesting issues are things like what happens if the target of the
element() function is a split inline.

Received on Saturday, 28 July 2012 01:32:45 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:01 UTC