[RFC Weston 00/10] Sub-surfaces v2

[Pekka Paalanen]

On Thu, 07 Mar 2013 12:32:21 +0100
Kai-Uwe Behrmann <ku.b at gmx.de> wrote:

> Am 07.03.2013 11:44, schrieb Pekka Paalanen:
> > On Thu, 07 Mar 2013 07:25:17 +0100
> > Kai-Uwe Behrmann <ku.b at gmx.de> wrote:
> >>> The biggest improvement over v1 is that we have some thought-out
> >>> commit behaviours. It is possible to resize a window so that all
> >>> surfaces stay in sync on screen, and it is also possible to have
> >>> sub-surfaces running on their own (i.e. without commit the
> >>> parent surface, too).
> >>
> >> What is the default behaviour of repainting in regards to Z-order? Draw
> >> all surfaces? I other words, is the possibility to have sub-surfaces
> >> running on their own only optional?
> >
> > Sorry, I don't understand the question.
> >
> > In v2 proposal, which does not support nesting, all sub-surfaces are
> > siblings. They have no effect on each other's rendering. Also, as they
> > are all siblings, Z-order is a completely orthogonal attribute to
> > commit mode or rendering.
> >
> > Nesting support is coming, though.
> >
> > Could you rephrase the question?
> 
> I will try.
> 
> Statement:
> The flattened output of overlapping transparent regions depend on the 
> intented order of painting the graph during compositing.
> 
> Question:
> Does your following annotation has a side effect on the painting(Z) 
> order of transparent content?
> 
>  >>> and it is also possible to have
>  >>> sub-surfaces running on their own (i.e. without commit the
>  >>> parent surface, too)

Hmm, no. Whether you commit or not on a parent surface, has no effect on
the Z-order of sub-surfaces on its own. How could it have? The parent
surface is still there in the same state it was before, if you don't
commit it.

Sub-surfaces running on their own simply means, that a
wl_surface.commit on such a sub-surface will be effective immediately,
instead of waiting for the parent surface to be committed. This
allows a widget in a sub-surface to animate on its own, without
requiring other surfaces to be committed every time it updates.

Committing new state to surfaces, and compositor's repainting are quite
orthogonal. The compositor is free to repaint as often or seldom as it
wants. Committing does not affect the Z-order or repainting order,
unless you explicitly change the Z-order with a place_above/below
request.

I guess I still cannot imagine what side-effects there could possibly
be.


Thanks,
pq