Re: [css-compositing] test suite for grouping

On Thu, Apr 18, 2013 at 3:25 PM, Simon Fraser <smfr@me.com> wrote:

> On Apr 18, 2013, at 8:00 AM, Rik Cabanier <cabanier@gmail.com> wrote:
>
> On Thu, Apr 18, 2013 at 7:12 AM, Robert O'Callahan <robert@ocallahan.org>wrote:
>
>> On Fri, Apr 19, 2013 at 2:01 AM, Dirk Schulze <dschulze@adobe.com> wrote:
>>
>>> On Apr 18, 2013, at 6:31 AM, Robert O'Callahan <robert@ocallahan.org>
>>> wrote:
>>> > Maybe you misunderstood me. I don't want to guarantee that the Gecko
>>> test results won't change in the future. We need to be able to change
>>> grouping to adjust our optimizations.
>>>
>>> To make this specification successful, we need to agree on some rules
>>> about grouping.
>>
>>
>> Which means that these features may severely constrain browser
>> optimizations in the future. And that means we have to consider whether
>> it's worth having the features as currently designed.
>>
>
> If there is no blending, the browser can do whatever it wants (as it
> currently does). Only when there's blending should it do something special.
>
>
>>
>> Maybe we could make progress if we introduced a CSS property that forces
>> its element to be a group and stacking context, *and* forces all its
>> children to be groups and stacking contexts, and then we say that
>> blending/compositing only works on those children, and that only the
>> siblings of a blended-composited element can be part of the background that
>> we blend/composite into.
>>
>
> That seems like it would introduce a lot of overhead. Why not simply list
> the cases where we want grouping and implement that.
> As some testcases point out, we might even want a group within an element
> so solving things with just stacking contexts won't work.
>
>
> I agree with Robert that we should not lock in grouping behavior when we
> don't have to.
>
> Is the problem here that it's the grouping of elements which do _not_ have
> the blending properties applied to them that's the issue?
>

You can partly see the issue in the patch for CSS blending:
https://bugs.webkit.org/show_bug.cgi?id=99200
RenderLayerCompositor.cpp was updated so if there was a layer that contains
a layer with accelerated blending, that layer itself should be accelerated.

The problem is that there is no definition of what establishes a
layer/group because it didn't used to make a difference.
The matrix that we're building, shows when browsers are currently creating
layers. Once we know the current behavior of all browsers, we can make a
union (so if WK doesn't create a layer but FF does, we choose to create a
layer) and define that to be the grouping.
This grouping ONLY needs to be done when there's blending.



> Maybe you'll have to add a property for things that need to behave
> predictably when something on top of them is blended.
>