| |||||||||||||
LFCS 2012: X and WaylandLFCS 2012: X and WaylandPosted Apr 11, 2012 20:43 UTC (Wed) by drag (subscriber, #31333)In reply to: LFCS 2012: X and Wayland by glandium Parent article: LFCS 2012: X and Wayland
> If applications handle their own decoration and Wayland does its own window management, how do we get the variety of window management systems we have now (tiling vs. "standard", virtual desktops, etc.)
I posted it in a previous article comments thread touching on this subject:
> How can I replace Wayland's Window Manager?
> The Wayland architecture integrates the display server, window manager and compositor into one process. You can think of Wayland as a toolkit for creating clients and compositors. It is not a specific single compositor or window manager. If you want a different window manager, you can write a new one.
That.
That way people can just build and modify existing behavior rather then having to write a entire new window management system from scratch. That way they can concentrate on the functionality they desire rather then get caught up in replicating basic/common functionality correctly. Which seems a much faster way to get a large amount of customization possible.
(Log in to post comments)
LFCS 2012: X and Wayland Posted Apr 12, 2012 19:43 UTC (Thu) by Fats (subscriber, #14882) [Link]
> > The Wayland architecture integrates the display server, window manager and compositor into one process. You can think of Wayland as a toolkit for creating clients and compositors. It is not a specific single compositor or window manager. If you want a different window manager, you can write a new one.
> That.
What is still not clear to me is what happens when a client finds it is too busy or too important to obey the minimize gadget or a window drag ? Would it behave the same as on Windows, e.g. that the window won't budge ? If there is one thing I really dislike about Windows it must be this. I find this important and relying on well behaving clients doesn't cut it for me.
greets,
LFCS 2012: X and Wayland Posted Apr 13, 2012 0:53 UTC (Fri) by hholzgra (subscriber, #11737) [Link]
+1
AFAIR even the AMIGA did better on that than Windos (although i'd not bet more than 50ยข on it, too many years have gone by since then)
LFCS 2012: X and Wayland Posted Apr 20, 2012 2:19 UTC (Fri) by tjc (subscriber, #137) [Link]
Amiga Intuition was a separate process from the client, so even if the client fell over the window could still be managed. In 1985. On a 7 Mhz processor!
LFCS 2012: X and Wayland Posted Apr 20, 2012 11:44 UTC (Fri) by dgm (subscriber, #49227) [Link]
The same is true for the Wayland compositor.
With X11 you currently have 3 processes:
1. X server
In Wayland you do away with the X server process. All it's duties unrelated to network communications (screen management, input handling) are incorporated into the compositor/window manager.
So, it will in fact look a lot more like Amiga's Intuition than current X does.
LFCS 2012: X and Wayland Posted Apr 13, 2012 7:48 UTC (Fri) by drag (subscriber, #31333) [Link]
Well....
I can alt-click a window to move it in Xfree even if the application is blocking and I happen to click on a portion of the window that the application itself is responsible for drawing.
Right?
So even though the application is drawing the main body I can still move it around by alt-clicking on the main body and dragging it even if the window is unresponsive.
So this does not seem to be a significant problem at all. All Wayland has to do is be aware of the what is the 'title bar' region of the window and be able to act accordingly when you click on that portion. It doesn't have to draw the title bar or close buttons to be aware of the them and be able to respond to clicks in the area of those items independently of the application itself.
LFCS 2012: X and Wayland Posted Apr 13, 2012 8:28 UTC (Fri) by khim (subscriber, #9252) [Link] Windows solves this problem with timeouts. Program can draw it's own decorations and process events in any way it wants to do that, but if it does not respond in timely fashion then OS imposes standard borders and allows you to do standard things (move/resize, close, etc).
LFCS 2012: X and Wayland Posted Apr 13, 2012 9:25 UTC (Fri) by dgm (subscriber, #49227) [Link]
This cannot apply to Wayland, because there's no concept of "draw your decorations" message. All drawing is application's business in Wayland, and done in a single step.
LFCS 2012: X and Wayland Posted Apr 13, 2012 9:34 UTC (Fri) by khim (subscriber, #9252) [Link] So what? Window manager can easily put it's own window with just a decorations and empty transparent body which will give the same affect.
LFCS 2012: X and Wayland Posted Apr 16, 2012 13:38 UTC (Mon) by dgm (subscriber, #49227) [Link]
Putting some standard borders is trivial, yes. The problem is detecting that the application is not drawing it's decorations, or more exactly, that it's not doing it so because it's hung or something (because it could be a feature, you know...)
A good alternative is let users point hung up applications themselves (using something like Xkill) and draw the "standard frame" then.
LFCS 2012: X and Wayland Posted Apr 13, 2012 9:30 UTC (Fri) by renox (subscriber, #23785) [Link]
> I can alt-click a window to move it in Xfree even if the application is blocking and I happen to click on a portion of the window that the application itself is responsible for drawing. Right?
Right: that's server-side decoration.
> All Wayland has to do is be aware of the what is the 'title bar' region of the window and be able to act accordingly when you click on that portion.
What you're suggesting is 'server side' window management, so you will have "ugly" window if the client doesn't answer fast enough, but the window will be resized/moved smoothly.
Wayland developers prefer (a), KDE developers (and I) prefer (b): they'll use their own compositor which will do server-side decoration instead of Weston.
LFCS 2012: X and Wayland Posted Apr 13, 2012 18:43 UTC (Fri) by Fats (subscriber, #14882) [Link]
> There is a tradeoff to be made:
> a- client side decoration: the windows will be always displayed consistently even when resizing, but the animation may become jerky/unresponsive when resizing or moving if applications are slow to answer. > b- server side decoration/management: moving or resizing windows will be animated smoothly but the content of a window when resizing can be "ugly" (incoherent) if the application doesn't answer fast enough.
To me it is clear. It has to be (b), (a) is a reason for me to not go for Wayland. Given that Wayland is using compositing for all windows the amount of uglyness in (b) will be limited: part of the window is cut off or not drawn yet.
greets,
LFCS 2012: X and Wayland Posted Apr 14, 2012 9:24 UTC (Sat) by renox (subscriber, #23785) [Link]
Well if you have a design like BeOS/Haiku where each application has a thread dedicated to the GUI, (a) may not be so bad as there should be no/vert rare slowdown of the application (it would also work very well with (b) of course).
As for network transparency, AFAIK VNC-like or XSpice-like are the only options for a future toolkit which would only know Wayland, OK for a LAN but for a WAN I'm not convinced that it would work well as I believe that client side decoration increase the number of round trip in some cases such as moving a window.
That said, Qt, GTK, EFL speak X so Wayland isn't a reason to be worried for WAN network transparency, the lack of integration of NX in X is a reason!
LFCS 2012: X and Wayland Posted Apr 14, 2012 18:09 UTC (Sat) by raven667 (subscriber, #5198) [Link]
I'm not worried about remoting over WAN links for Wayland because there are 20+ years of research and deployed protocols and I think that this is pretty much a solved problem. The real issue is that it'll take several years to implement something great but implementing something good enough should be easy. As you point out X11 isn't going anywhere so the situation can only get better and not worse.
LFCS 2012: X and Wayland Posted Apr 15, 2012 9:27 UTC (Sun) by renox (subscriber, #23785) [Link]
No, the real issue isn't the implementation: the real issue is having the toolkits agree on a common implementation.
DEB vs RPM show that it's quite possible, even for a basic infrastructure to have a division which hurts everybody (wasted time, efforts) which will stay for a long time.
LFCS 2012: X and Wayland Posted Apr 19, 2012 21:25 UTC (Thu) by wmf (guest, #33791) [Link]
That's why network transparency should be implemented once by Wayland itself in a toolkit-independent way.
LFCS 2012: X and Wayland Posted Apr 19, 2012 22:00 UTC (Thu) by nybble41 (subscriber, #55106) [Link]
Wayland is the wrong place for network transparency. When people speak of "network transparency" what they really mean is "efficient remote rendering", and Wayland does not define a rendering protocol. It is strictly a protocol for accessing the screen and input devices.
What we need is not a remote version of the Wayland protocol, which is inherently _local_ due to the use of shared memory, but general-purpose protocols for remote rendering and input, targeting Wayland for access to the hardware. For now, the X protocol can serve that purpose, as can single-window adaptations of VNC. Future protocols can take similar advantage of Wayland for the low-level hardware interfaces, and concentrate instead on remote rendering.
LFCS 2012: X and Wayland Posted Apr 22, 2012 16:48 UTC (Sun) by VITTUIX-MAN (guest, #82895) [Link]
Wayland is exactly the right place to implement network transparency, in XPRA way in a network aware compositor.
This does all the things we love in networked X, that is mainly rootlessness is the default and it would allow plugging into a running session, so connection problems would no longer close all open programs.
LFCS 2012: X and Wayland Posted Apr 22, 2012 17:16 UTC (Sun) by renox (subscriber, #23785) [Link]
> Wayland is exactly the right place to implement network transparency, in XPRA way in a network aware compositor.
For LAN yes, but as I said here (http://lwn.net/Articles/493461/), WAN will probably suck unless there are many changes.
In my understanding currently:
- Wayland has very limited server rendering, so to be able to have XRender-way to display text, you'd have to change it significantly, until then Wayland will use much more bandwith to display text than X (if the toolkit use the XRender extension of course).
LFCS 2012: X and Wayland Posted Apr 20, 2012 7:30 UTC (Fri) by renox (subscriber, #23785) [Link]
> That's why network transparency should be implemented once by Wayland itself in a toolkit-independent way.
Except that it isn't possible to have network transparency which works well in a WAN with Wayland, without changing radically how Wayland works.
Two examples:
LFCS 2012: X and Wayland Posted Apr 20, 2012 9:56 UTC (Fri) by cortana (subscriber, #24596) [Link]
Do modern (as in, recently written) X clients actually use this font caching mechanism? I thought they all used FreeType (through various wrapping layers) to render on the client side these days.
LFCS 2012: X and Wayland Posted Apr 20, 2012 11:45 UTC (Fri) by renox (subscriber, #23785) [Link]
You misunderstood what I wrote: they render the font on the client, send the image of the letters *once* on the server, and can now display text very efficiently from a bandwith POV (all this if the XServer has the XRender extension).
LFCS 2012: X and Wayland Posted Apr 20, 2012 12:04 UTC (Fri) by chris.wilson (subscriber, #42619) [Link]
With the Render protocol, glyph images are no longer generated by the server but rather by the client who uploads a set of glyph images for a font. Typically, the client does use FreeType to render the individual glyph images. The server de-duplicates those images across all the clients and maintains the glyph image for later use by the client. When the client then renders some text it converts the string of characters into a set of (font, glyph index, position) tuples and sends that as a rendering request along with the operator to use and source pattern to apply. That request is passed to the driver, which typically prescans the request and uploads unseen glyphs into a texture atlas cache (using random replacement of old glyph entries to maintain fairness across all clients) and then converts it into a command stream for the GPU. By using a texture atlas, the number of state changes required for the command stream is minimised, though still one or two extra are incurred in order to adhere to the Render semantics.
In contrast, the core protocol differs in that the server renders the glyph images itself, and so has a fixed concepts of fonts and glyphs and needs to inform the client of the font/glyph metrics, and in the various semantics of the operators and patterns. That the core fonts were only bitmaps and so were easier for hardware to implement and are still faster than compositing glyphs using Render, is an implementation detail.
LFCS 2012: X and Wayland Posted Apr 20, 2012 18:26 UTC (Fri) by raven667 (subscriber, #5198) [Link]
> Except that it isn't possible to have network transparency which works well in a WAN with Wayland, without changing radically how Wayland works.
I really doubt that's true, maybe you are unfamiliar with remote rendering protocols other than X?
> Wayland developpers prefer CSD decoration: think about what this imply in term of latency when you want to move a window in a WAN vs server side management of windows.
I don't think client side decorations have anything to do with window management and I can't envision the problem you seem to be describing. I can't see how window move performance would be affected based on which process is drawing the border, in either case you have a rectangle that needs to be moved around. In fact I would expect the client side decorations to be faster because the current X architecture where window management and borders are in the same process requires extra round trips and coordination between the application, X and the window manger to make sure the borders are adjacent and not overlapping the window contents as it is being moved. This architecture also causes a lot of tearing, as the window contents and window border are drawn at different times by different apps.
> Also an X client can send an image of each letter only once on the server, cache it there, and then reuse it
As the people who are designing wayland (primarily a display protocol for local apps) are also the ones who designed the font caching you describe I think they can figure out how to make an efficient remote protocol if they apply themselves to it 8-)
LFCS 2012: X and Wayland Posted Apr 16, 2012 14:14 UTC (Mon) by dgm (subscriber, #49227) [Link]
>> I can alt-click a window to move it in Xfree even if the application is blocking and I happen to click on a portion of the window that the application itself is responsible for drawing. Right?
>Right: that's server-side decoration.
No, that's window management. Decoration is just drawing borders around the window rectangle. in Wayland you still have a window manager, it's the compositor. The compositor does move windows around, hide or display them. It can do other things like distort them or map them to the sides of a spinning cube.
> a- client side decoration: the windows will be always displayed consistently even when resizing, but the animation may become jerky/unresponsive when resizing or moving if applications are slow to answer.
As I said, the compositor can distort windows, so nothing prevents it from doing resizing the smooth and ugly way if needed. This will mean that, usually, applications will simple resize nice and smoothly, but if for some reason an application cannot resize fast enough, a good compositor can interpolate frames and keep the resizing smooth. It's the best of both worlds.
And again, this has nothing to do with decorations, but with window management. Currently the X11 window manager does both, but in Wayland those tasks are split between the application and the compositor.
LFCS 2012: X and Wayland Posted Apr 16, 2012 15:00 UTC (Mon) by renox (subscriber, #23785) [Link]
>>> I can alt-click a window to move it in Xfree even if the application is blocking and I happen to click on a portion of the window that the application itself is responsible for drawing. Right?
>>Right: that's server-side decoration. > No, that's window management.
In current systems server-side decoration imply server side window management, so I'd say you're nitpicking, but yes that's server side window management.
> [cut] a good compositor can interpolate frames and keep the resizing smooth
Not sure this would be so good: the client already took "too long" to answer and then the animation between both frames would add also some delay..
LFCS 2012: X and Wayland Posted Apr 16, 2012 17:11 UTC (Mon) by Fats (subscriber, #14882) [Link]
> No, that's window management. Decoration is just drawing borders around the window rectangle. in Wayland you still have a window manager, it's the compositor. The compositor does move windows around, hide or display them. It can do other things like distort them or map them to the sides of a spinning cube.
I don't understand it. How does the compositor know that it has to move or minimize a window if the client is responsible for the window drag bar and the minimization widgets ?
LFCS 2012: X and Wayland Posted Apr 16, 2012 17:39 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]
Easy. Add an 'override mode' to the compositor.
If a window doesn't respond to messages in (say) 2 seconds then the compositor can draw overlay on it with largish "Minimize" and "Force Close" buttons. Additionally, you can add keyboard/mouse shortcuts for that (for example, this overlay can be brought up by triple clicking on a window, etc).
LFCS 2012: X and Wayland Posted Apr 17, 2012 8:07 UTC (Tue) by renox (subscriber, #23785) [Link]
>If a window doesn't respond to messages
And to a specific "ping message" I think as it should be possible for a window to ignore some events.
> then the compositor can draw overlay on it with largish "Minimize" and "Force Close" buttons.
"Force Close" OK but I'm not so sure about minimizing/hiding: I thought that this part was handled by the clients.
LFCS 2012: X and Wayland Posted Apr 17, 2012 8:21 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]
>And to a specific "ping message" I think as it should be possible for a window to ignore some events.
Yup. Patches to add 'ping event' and shading of inactive windows have just been posted today: http://www.phoronix.com/scan.php?page=news_item&px=MT...
>"Force Close" OK but I'm not so sure about minimizing/hiding: I thought that this part was handled by the clients.
Compositor can hide/minimize windows forcibly (and restore them back if unresponsive application recovers). I.e. it might look like:
Something like this.
LFCS 2012: X and Wayland Posted Apr 17, 2012 17:21 UTC (Tue) by Fats (subscriber, #14882) [Link]
> Easy. Add an 'override mode' to the compositor.
So is this in the Wayland architecture ?
LFCS 2012: X and Wayland Posted Apr 17, 2012 18:14 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]
It's not yet implemented (the very basic 'fading of inactive clients' was pushed yesterday) but it's certainly within the Wayland architecture and perfectly doable.
LFCS 2012: X and Wayland Posted Apr 17, 2012 19:07 UTC (Tue) by Fats (subscriber, #14882) [Link]
OK, now still add per-client network transparancy (not per-desktop) optionally with NX-style reconnectability and then I may consider Wayland as an option.
LFCS 2012: X and Wayland Posted Apr 17, 2012 19:16 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]
It's certainly possible. As I understand, something like xpra for Wayland is in the works.
LFCS 2012: X and Wayland Posted Apr 13, 2012 12:13 UTC (Fri) by HelloWorld (guest, #56129) [Link]
With X, you're relying on well-behaving clients all the time. Applications can stop the window manager from drawing decorations, they can move windows around however they like etc. etc.. Yet, things seem to more or less work.
LFCS 2012: X and Wayland Posted Apr 13, 2012 16:21 UTC (Fri) by alankila (subscriber, #47141) [Link]
And there is X grab, the ability of a single client to prevent you from further interacting with the desktop.
LFCS 2012: X and Wayland Posted Apr 17, 2012 17:24 UTC (Tue) by Fats (subscriber, #14882) [Link]
> And there is X grab, the ability of a single client to prevent you from further interacting with the desktop.
And programs who do that trick to me 2 times gets deinstalled. Thing is that it is more uncommon for an application to grab display than to need to reply to minimize or move requests.
|
|||||||||||||