Linked by martini on Tue 23rd Oct 2012 22:02 UTC
X11, Window Managers Wayland 1.0 was officialy released on October 22. Wayland is a protocol for a compositor to talk to its clients as well as a C library implementation of that protocol. The compositor can be a standalone display server running on Linux kernel modesetting and evdev input devices, an X application, or a wayland client itself. The clients can be traditional applications, X servers (rootless or fullscreen) or other display servers.
Thread beginning with comment 540131
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[5]: Comment by stabbyjones
by silix on Fri 26th Oct 2012 11:18 UTC in reply to "RE[4]: Comment by stabbyjones"
Member since:

currently the application provide one buffer for the complete window (decoration plus content),

only one surface for the whole window?

correct me if i'm wrong, but i got it that surfaces are fully redrawn in response to events they are the target for
and every visual object gets assigned its own surface so as to avoid redrawing everything and all (title-/menu-/scroll-/tool-bars, widgets) whenever something happens somewhere else (especially in the actual work area, eg the canvas in a paint program)
which seemed quite inefficient..

that's why i was thinking that the compositor could do anything including replace the application's decoration on the fly - never mind...
but still, it can superimpose its own (or at least a box with its own control widgets) aligned to the app's window, without requiring a titlebar description protocol...

you're suggesting that the application sends two buffer one for the inside and one for the decoration

rather than suggesting, i was more like expecting it to be so (actually not just two, but possibly one surface per widget or - for "frame" like decorations - frame edge)
moreover, since i thought the point of compositing was to leverage the gpu's hw rendering capabilities, and surfaces are actually handles to objects in gpu memory (thus shareable at hw level), the application wouldnt "send" anything (at least not to the compositor, but to the gpu, and only when the surface needs redraw)
and, even when the decoration is affected, only that would need to be "sent"

if the server detect that the client isn't answering fast enough it can do itself the resizing?

the point was that the server shouldnt try to "detect" anything
not by pinging the application and using round trips, anyway - one could reply to a ping from the compositor in a separate thread, and the application would appear responsive even though the gui loop is busy...

giving the user the possibility to toggle to an alternate mode in which control (minimize, close etc) buttons are provided by the compositor, at any time, would be much more useful than any heuristic...

Reply Parent Score: 2