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

On Wed, Mar 6, 2013 at 3:19 PM, L. David Baron <dbaron@dbaron.org> wrote:

> On Wednesday 2013-03-06 13:06 -0800, Rik Cabanier wrote:
> > On Tue, Mar 5, 2013 at 11:05 PM, L. David Baron <dbaron@dbaron.org>
> wrote:
> > > However, what I think you're proposing -- that the background
> > > available for blending is based on what's in the stacking context --
> > > seems like it's potentially quite expensive, in that it would force
> > > implementations to use a separate graphical buffer for anything that
> > > creates a stacking context, or at the very least anything that
> > > creates a stacking context and has a descendant, in the same
> > > stacking context, with background-blend-mode.
> >
> >
> > That is correct. Are there cases where a stacking context doesn't create
> a
> > buffer?
> > From my experiments, only 2d transforms skip this step (and even then
> they
> > will sometimes create one). From talking to Simon Fraser, this was done
> > intentional to have good quality scaling.
> >
> >
> > >  I think it would also
> > > require that implementations *not* use a separate graphical buffer
> > > for anything in that stacking context that might end up underneath
> > > the background, since any such elements would need to be
> > > incorporated into the buffer in order to be composited against.
> > >
> >
> > I don't think there's that requirement. If an implementation used a
> > separate buffer, that buffer would be composited by the time the element
> > with blending accesses the backdrop.
> >
> >
> > > I don't believe your proposed patches to Firefox [2] do this.
> > >
> >
> > That is correct. The patch simply adds support for blending to background
> > images.
> > Only a non-default blend mode to an *element* will establish a new
> stacking
> > context.
>
> It's not that simple.  The background image still has to be blended
> on top of something.  You're saying that, according to the spec, the
> destination that it's blended with is what is drawn below it within
> the same stacking context.  And while that might actually be what
> you end up with on some testcases, nothing in your patch actually
> ensures that the destination buffer contains (a) everything below
> the element that is in the same stacking context and (b) nothing
> else.  That's not an invariant that Gecko has ever maintained or
> needed to maintain.
>

Sure. We should treat those cases as bugs and fix them. I would be
surprised if that proved to a be a lot of work.


>
>
> > > It's also, as far as I can tell, not specified in the spec [3].
> > >
> >
> > Correct. Images are buffers anyway :-)
> > It wouldn't make any sense to call a background image a buffer.
>
> You still need to specify the destination they're being blended
> with.
>
> > > I think it would make much more sense to limit the first level of a
> > > compositing and blending specification to the compositing/blending
> > > of elements that establish stacking contexts (and are therefore
> > > atomic).  This can include adding new features that cause the
> > > creation of stacking contexts when the features are used.
> > >
> >
> > I *think* that's what I'm trying to do.
>
> But it's not what you're doing.
>
> > background-blend-mode works on atomic items that don't need special
> > treatment.
>
> Background images themselves are atomic, but you still need to
> specify what they're blended with.  And since they don't create a
> stacking context, they sit in the middle of the very-complicated
> rules for painting stuff within a stacking context.
>

yes, but your spec describes that order (except it doesn't handle multiple
backgrounds yet) so that should not be a big deal.


>
> See http://dbaron.org/log/20130306-compositing-blending for more
> explanation of what I mean.


Great!  I will read that post.