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

On Thu, Mar 14, 2013 at 3:53 AM, Robert O'Callahan <robert@ocallahan.org>wrote:

> On Thu, Mar 14, 2013 at 5:00 PM, Rik Cabanier <cabanier@gmail.com> wrote:
>
>> I create a jsfiddle testcase: http://jsfiddle.net/vSjXM/5/
>> and attached the rendering of WebKit and Firefox that has the blending
>> patch. (https://bugzilla.mozilla.org/show_bug.cgi?id=841601)
>>
>> The behavior you described indeed happens. As soon as an element is
>> scrolled, it goes to an offscreen bitmap (ffox_scrolling vs
>> ffox_no_scrolling).
>> Webkit does not seems to suffer from this.
>>
>
> You mean "Webkit doesn't do this optimization" :-).
>

yeah :-)
FF doesn't seem to do the 'position: fixed' optimization. There was a
report on the chromium graphics mailing list that seemed to indicate that
it improves performance.
This is actually a sign that browsers should standardize this. Pages might
have different performance characteristics because they don't specify what
operations are expense. This makes it harder for authors.


>
>
>> Is this something we can detect and disable if we detect blending in the
>> element?
>>
> Another difference is that 'position: fixed' didn't create a buffer in
>> Firefox, but it did in WebKit.
>> It does create a buffer is the scrollable div goes under it; just like
>> you said :-)
>>
>> These differences should all be fixed so blending and filter chains that
>> access the background can work.
>>
>
> I'm not sure what you're suggesting. Are you suggesting we write Webkit's
> buffer-creation rules into a spec and modify other browsers to follow those
> rules if blending is detected in the page?
>

As Dirk said, we need to come up with a set of rules that specify when
these special stacking contexts are created. This will most likely need
changes on all browsers.
Current browser behavior and optimization should not change (that code is
there for a good reason); only in the new context of blending and filtering
should there be new behavior.