Re: Utility of background-composite and background-blend-mode?

On Thu, Mar 7, 2013 at 11:27 AM, Rik Cabanier <cabanier@gmail.com> wrote:

> On Wed, Mar 6, 2013 at 12:57 AM, Robert O'Callahan <robert@ocallahan.org>wrote:
>
>> On Wed, Mar 6, 2013 at 6:16 PM, Rik Cabanier <cabanier@gmail.com> wrote:
>>
>>>  On Tue, Mar 5, 2013 at 6:06 PM, Robert O'Callahan <robert@ocallahan.org
>>> > wrote:
>>>
>>>> Hmm. I see that the spec says "Everything in CSS that creates a stacking
>>>> context <http://www.w3.org/TR/CSS21/zindex.html> must be considered a
>>>> group." I don't like that. An ancestor that created a stacking context just
>>>> because it's absolute-positioned with z-index not 'auto' shouldn't impact
>>>> blending and shouldn't create an isolated group; it'll create a performance
>>>> penalty for existing Web content.
>>>>
>>>
>>> I agree,but it's just reality.
>>> The graphics libraries that support the browser's rendering, are not
>>> powerful enough to create true, non-isolated groups. Even if they did, I
>>> would have a hard time convincing mobile browsers since it takes a lot more
>>> processing and extra buffers to implement.
>>>
>>
>> I don't understand your answer. I'm arguing that normally stacking
>> contexts should not be considered groups at all, precisely because we don't
>> want to have to start using temporary buffers where we currently don't.
>>
>
> When does this not happen? (I know 2d transforms sometimes don't)
> I think this should be specified. Filters are running into the same issue.
>

Yes, it should be specified. I gave you an example up above: "An ancestor
that created a stacking context just because it's absolute-positioned with
z-index not 'auto' ".

 It's complicated.
> According to the SVG spec, that <g> should be a group with a separate
> buffer and set to accumulate (= the background is copied into it) so the
> rect and circle blend.
> However, FF and WK optimize this case and simply treat the <g> as a
> passthrough. The result is that circle and rect still blend. (I'm unsure
> what IE does)
> I would like to specify that behavior. This will help filters as well
> since it allows us to implement background-image [1]
>

Right. That might help, because the spec is currently written would require
us to do some potentially-hairy optimizations to not regress performance of
existing content.


> OK, but it's totally unclear for example whether each text shadow for a
>> text node is an independent shape or whether all the text-shadows together
>> constitute a single shape. Or for that matter, whether the text-shadows
>> constitute a different shape to the text itself. It's unclear whether, when
>> a node breaks into multiple boxes, the text, background or borders for
>> different boxes of the node are separate shapes or a single shape. Etc.
>> This all needs to be specified, for everything CSS can render.
>>
>
> I agree. I will update the spec text.
>

Note that once you've done that, we might have to spend a lot of time
comparing implementations and fixing them to agree on those shapes :-(. And
of course someone will have to build a test suite; it's going to have to be
large.

Rob
-- 
Wrfhf pnyyrq gurz gbtrgure naq fnvq, “Lbh xabj gung gur ehyref bs gur
Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl
bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat
lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir
— whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb
tvir uvf yvsr nf n enafbz sbe znal.” [Znggurj 20:25-28]