EFL/Wayland and xdg-shell

[Pekka Paalanen]

On Tue, 14 Apr 2015 10:27:48 -0500
Derek Foreman <derekf at osg.samsung.com> wrote:

> On 14/04/15 01:38 AM, Giulio Camuffo wrote:
> > 2015-04-14 6:33 GMT+03:00 Derek Foreman <derekf at osg.samsung.com>:
> >> On 13/04/15 07:31 PM, Daniel Stone wrote:
> >>> Hi,
> >>>
> >>> On 14 April 2015 at 01:02, Bryce Harrington <bryce at osg.samsung.com> wrote:
> >>>> For purposes of discussion, an example might be rotated windows.  The
> >>>> set geometry api takes x, y, height, and width.  How would you specify
> >>>> rotation angle?
> >>>
> >>> The window doesn't know it's rotated. The rotation occurs as part of
> >>> the translation into global co-ordinate space (perhaps more than one,
> >>> perhaps multiple instances, etc), which the client is unaware of. If
> >>> it wasn't unaware of it, things like input would also be broken.
> >>
> >> It's intended to allow for the usual level of EFL/Enlightenment eye candy.
> >>
> >> I don't think having a window perpetually at a 35 degree angle is the
> >> intended use case - having the app know that the screen has been rotated
> >> so it can participate in a glorious animation sequence while its window
> >> is transitioning from 0 to 90 degree rotation is.
> > 
> > When the output is rotated you get a geometry event with the transform
> > so you can animate all you want, so that use case is already covered.
> 
> Eeeh, sort of.  That's kind of an after the fact signal.
> 
> As an example I suspect I'm going to overuse in the coming days: If the
> compositor is doing some kind of window animation the drop shadows will
> all be wrong until the final frame when it sends the output update.
> 
> For a full screen application I think that event is enough though.
> 
> For a really nice example of this done right, look at an iPad's settings
> application after you rotate the tablet.  Everything slides nicely into
> place.  Of course, that's a full screen app...
> 
> For a screen full of app windows that want to all do that at the same
> time things get complicated.  The app would have to make a big window
> (axis aligned bounding box of the rotating window) and shape away parts
> of it with alpha?
> 
> This is of course possible, but I think it could be "better" if the
> compositor helped out a bit...  Either by informing the app of its
> orientation while performing the rotation, or allowing the app to set
> its window rotation so it could handle it itself.

Sounds like it would be relatively easy to add a protocol extension
via a new global interface, where a client can subscribe to
orientation/angle events for a window. These events would then be
always sent just before the basic configure event; the angle event
would be an extension of the configure event.

The configure events carry a serial, so the compositor would also
know which angle event a new attach+commit corresponds to.

If clients are expected to render something based on the angle, you
are unavoidably facing the problem "what if a client is too slow".
How long does the compositor wait until it gives up and just
renders? Well, less than a frame period I suppose.

Considering you might have laggy clients, I could imagine that the
compositor doing the surface rotation would be less visually bad
than clients rotating completely themselves. The compositor would
guarantee all windows rotate in sync, only the angle-dependant
bling per window might be off. Dunno, just a hunch.

That would work also for windows that do not subscribe to angle
events. The compositor would just rotate them all the same.

IOW, here is a proposed design, that:
- does not require any changes to the basic shell protocols
- is an optional add-on for both clients and servers
- works adequately also if clients do not opt-in

This design is also extendable to any kind of things you might
imagine; like specifying where is the light that is shining on the
window etc. so the client can draw highlights properly.


Thanks,
pq