Keith Packard has been working on the X window system since the early days, but more recently has been doing lots of work to enable its replacement. X has long held the position as the way that graphics is done on Linux (and other Unix) systems, but that is changing. He came to the Linux Foundation Collaboration Summit, which was held April 3-5 in San Francisco, to talk about the Wayland protocol and the Weston server, and how they could interoperate with X. Wayland looks to be an interesting change for desktop graphics on Linux.
Wayland is an alternative window system, and is part of long-term effort to integrate more modern technology into the Linux desktop. But there are lots of existing X applications out there that need a migration path so that they don't have to be rewritten. That's part of the plan too, Packard said.
The current architecture of X has it rendering via the kernel and getting input from the kernel. The X server handles the geometry of the screen. Packard said that X isn't doing anything other than multiplexing output to the screen, while demultiplexing input. These days, X is generally run with a compositing window manager, so applications create graphics that get sent to the X server, which sends it to the window manager that does the OpenGL rendering, before handing it back to the X server, which then gives it to the kernel to actually get it on the screen.
That is a complicated path that can be simplified by merging the compositor into the window manager. That gets rid of the extra compositor process, which simplifies things considerably. For Wayland, the Weston server is the merger of the two separate pieces in X.
From an application's perspective, there aren't that many changes. It still talks to the server for geometry handling and still talks to the kernel or server to create its graphics. But the protocol is different, which will save a bunch of time, system complexity, and memory, Packard said.
Some applications will still need to talk X, however. One way to do that would be to make Wayland talk X too, but that would violate one of the goals of the project, which is to be lightweight. Weston is currently around 10,000 lines of code, so gluing in "half a million lines of X code" is not the right approach.
Instead, a new xwayland component was created. The X server will still be running, and applications will talk to it as they do now, but that server will talk to the xwayland hardware backend that will in turn talk to Weston. This is similar to what is done to support X on Mac OS X and Windows, which normally "sucks for performance", but the Wayland developers have come up with a way around that problem.
An application can do OpenGL or VAAPI (Video Acceleration API) rendering via the kernel in a buffer that is owned by the X server. The server passes that buffer to Weston via xwayland, but it is just a handle that is passed, not the actual data. The handles are just "tiny little names", he said, so there is very little bandwidth required to transfer them. It does require an extra context switch, but shouldn't add any latency compared to existing X.
There are really only a few differences between X and Wayland; Packard was only able to come up with three. First, X has an external compositor, while Wayland's is internal. X deliberately put the compositor into a separate process because people wanted to experiment with compositing. In addition, the X server generally runs as root, so pushing the compositing code out of the server itself was safer. It has been a successful experiment overall, but it does add some latency and requires that identical state information is held by both the X server and compositor. Both have all of the information about all of the windows on the screen, and the compositor has to mirror the X server data structures and do incremental updates to those based on damage events.
Second, X has external window management, and Wayland internalizes that. The reason X did that originally was because of a lack of shared libraries in 1987 when window management was added. In order to share common user interface (UI) elements between applications, they had to be centralized in an external window manager. One nice bonus of that decision is that an application's window can still be managed (e.g. minimized) even if the application itself locks up. That is a side effect of having a common UI for all the applications on the screen.
Lastly, X applications do not paint their window decorations, while Wayland applications will need to. This is why a Qt application today in a Gtk environment gets Gtk window decorations. In Wayland, clients will need to do their own decorations, but the toolkits (e.g. Qt, Gtk) already know how to do so. Toolkits have been using window manager hints to get the window manager to decorate the way they want for years, now the toolkits will just do it themselves.
One nice benefit of working on free software is that "we own the whole stack", so whatever changes are needed can just be made. The last seven years have been spent moving things out of the X server and into the kernel. Things like PCI mappings, mode setting, rendering, and more are all in the kernel now so they can be shared by all window systems and applications. In addition, any window system can use OpenGL just by using the libraries that are available. The same OpenGL library can be used by both X and Wayland.
Several large barriers to entry for new window systems have been removed. OpenGL support is just one of those. The VAAPI code is "window system agnostic" now as well. Mode setting, which was a "huge barrier to entry" is now available to any window system because it lives in the kernel. Similarly, Wayland can just use the kernel execution management code to get accelerated graphics rendering. In addition, because they had the ability to fix both X and Wayland, they could make performance improvements like using handles instead of passing buffers around.
The performance of X typically becomes "abysmal" when it runs on top of another window system like Windows or Mac OS X because the server has to do a lot of bulk memory copies. But, because Wayland is cooperating with X, you get "full speed 2D rendering" while direct rendering is unchanged. Buffer swaps will happen every 16ms, when the X server tells xwayland it has new content and Weston tells the kernel to display it. Putting X atop Wayland will actually "reduce the context switches to once every 16ms", which may make it perform better than native X, Packard said. He doesn't have any numbers, and the effect will likely be imperceptible, but it could be faster. From the audience, Greg Kroah-Hartman also noted that it may result in power savings.
"It's not all ponies and rainbows", he said, as there are still some problems that need to be addressed. One is that X atop Wayland will still require an X window manager. The current plan is to have a Wayland-specific window manager that will translate from the X domain to the Wayland domain. It will take size hints, for example, and talk to Weston using the Wayland protocol to handle the hints. It will also have to provide window decorations, which is an "opportunity for more confusion on the Linux desktop", Packard said. Because desktop environments have enforced a particular style of decorations via their window manager, all applications on the desktop had the same decorations regardless of the toolkit used, but that will no longer be true when each toolkit does its own decorations.
It took around 50 patches to the X server to make it work with Wayland, which is "much much easier" than it was to get X working on Windows, he said. The patches were rebased on the 1.12 server code and mostly cover changing the input handling so that it comes from Weston. X video drivers also had to change, once again mostly to defer things like mode setting and acquisition of the DRM master to Weston. In addition, some "ugly hacks" for window moving and resizing were replaced by the X/Wayland window manager.
The window manager that is part of Weston needs client-side window decorations so that they can be painted into the same buffer as the rest of the application's output. That way, scaling or rotating the output will properly handle the window decorations as well. In addition, it simplifies Weston by not requiring a lot of UI code to handle the decorations, and the applications (or toolkits) can respond appropriately to events from the decorations.
For example, resizing windows in X is currently "messy" and that causes "ugly output". But that will be fixed with Wayland. In addition, with client-side decorations, those decorations no longer need to be rectangular, so applications are free to create decorations of their own size and shape. There are some acceleration features in Weston so that applications can tell it to move a window following the mouse, or indicate a place for users to click to minimize a stuck application.
The X/Wayland window manager will have to handle decorations as well as dealing with ICCCM (inter-client communications conventions manual) and EWMH (extended window manager hints). That means it will need to "implement all the bugs in X", but it stops there, he said, and the X/Wayland window manager will talk "nice stuff" to Wayland. For example, there is a huge amount of ICCCM that deals with installing and managing color maps that no one uses anymore, which will be handled directly by the window manager.
X was created before there was MIME or Unicode, so there are many pages expended in the X specifications to do things that are more easily handled with MIME types and UTF-8 these days. For cut-and-paste and drag-and-drop, Wayland uses MIME-labeled UTF-8 encoded objects. For client-to-client data transfer, one client just hands a file descriptor to Weston which hands it to the other client. That eliminates another ten pages of ICCCM which "reimplemented TCP on top of X properties".
The X server could be started automatically at session initialization time, but that would slow down session startup and add extra memory overhead. It could be started manually by the user instead, but a better way is for Weston to listen on the X socket. When a client connects, Weston will launch X and pass the sockets to the X server. When the last X client closes, the X server can then exit. Kroah-Hartman asked about using systemd to start X, but Packard said that Lennart Poettering indicated that systemd cannot start X, though he's not sure why that is. In any case, it is only 20 lines of code in Weston.
There are, of course, some remaining issues to be worked on. For one thing, Wayland input handling is still in flux. There are questions surrounding keyboard support, as well as lots of code needed to support touchscreens and touch pads. There has been a lot of work on gestures and global system-wide touch support that will come to the Wayland environment with Xinput 2.2 support.
Another area that needs to be worked on is remote Wayland applications. The X community has had this capability for a long time and would like to be able to continue to use it. Supporting remote Wayland applications is not fundamentally different from local applications, he said. Applications will still create a new image and deliver it to the window server. In the local case, though, the pixels don't need to be transferred, but over the network, there is no shared memory between application and server.
There are "lots of nice network image transports", Packard said, that could be used to transfer the image data. That data could be compressed, perhaps even using a lossy compression, then sent to the server. Both sides could use any available hardware assistance (e.g. MPEG encode/decode), which would help with performance. Wayland avoids one of the major sources of latency in X, which is round-trips, so remote Wayland may actually have better performance than remote X. There are still lots of things to try, he said, but that's the current plan of attack.
The xwayland X server backend is working today. It redirects windows correctly and is started automatically. The synthetic keyboard and mouse that use the current Wayland keyboard handling is also working. The Intel video drivers bypass mode setting to work in Wayland environments. The X/Wayland window manager, cut-and-paste and drag-and-drop, as well as Xinput 2.2 support (for things like scroll wheels and touchscreens) are all things that he listed as still needing to be done. But it is clear that we are well on our way to having Wayland-based desktops that can still support the vast array of legacy X applications. It will be an interesting transition to watch.
LFCS 2012: X and Wayland
Posted Apr 11, 2012 19:26 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]
you will end up with different windows on the desktop with vastly different decorations, and with the Mac/Unity fad, some will have the min/max/close buttons on the left, and some on the right, all with different symbols....
This is the sort of change that the Desktop Environment folks who think that everyone runs only their Desktop Apps are going to love, but will make life worse for real users who don't limit their apps to one particular DE's "blessed" set of apps.
LFCS 2012: X and Wayland
Posted Apr 11, 2012 19:49 UTC (Wed) by quintesse (subscriber, #14569) [Link]
LFCS 2012: X and Wayland
Posted Apr 11, 2012 20:01 UTC (Wed) by apoelstra (subscriber, #75205) [Link]
I do. When an application merely "looks wrong", that's fine, although if the decorations were all in the wrong place and inconsistent with everything else, that'd be very irritating, and from the user's perspective, an awful regression.
But when applications provide no "quit" functionality or shortcut (I've seen many that are like this, assuming the WM will take care of them), or they lock up, then my window manager will save me. I've got a tiling manager where I can right-click on the title bar, click "Kill", and it will send SIGKILL to the application. (There is also a keybinding for SIGTERM, but I can never remember what it is.)
The bigger issue, IMHO, is still the lack of tiling window managers. I have no interest in manually resizing and moving windows, especially when it's up to the application to provide me a sane way to do it.
LFCS 2012: X and Wayland
Posted Apr 11, 2012 20:06 UTC (Wed) by quintesse (subscriber, #14569) [Link]
LFCS 2012: X and Wayland
Posted Apr 12, 2012 19:37 UTC (Thu) by aleXXX (subscriber, #2742) [Link]
Alex
LFCS 2012: X and Wayland
Posted Apr 13, 2012 0:21 UTC (Fri) by robert_s (subscriber, #42402) [Link]
LFCS 2012: X and Wayland
Posted Apr 11, 2012 20:08 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]
functional changes like where the maximize/minimize/close buttons are and what they look like are much more significant.
I'm also worried about these being under the control (and therefor subject to problems with) the applications. How long will it be before there are apps where the 'close' button on the window actually does something else?
LFCS 2012: X and Wayland
Posted Apr 11, 2012 20:23 UTC (Wed) by quintesse (subscriber, #14569) [Link]
LFCS 2012: X and Wayland
Posted Apr 13, 2012 0:19 UTC (Fri) by robert_s (subscriber, #42402) [Link]
That's a ridiculous example - nobody would ever do that because it is functionally illogical. However, the details of window management are very subjective, to do with taste, opinion and preference. Different people have different ideas (and strong opinions) over how things "should" be.
We are talking about the same software community that ended up with a whole GNOME fork based around the order of the OK/Cancel buttons, remember?
"Window managers" answer the question correctly here by saying "the correct behaviour is what the specific _user_ wants".
LFCS 2012: X and Wayland
Posted Apr 13, 2012 1:06 UTC (Fri) by quintesse (subscriber, #14569) [Link]
LFCS 2012: X and Wayland
Posted Apr 13, 2012 20:13 UTC (Fri) by k8to (subscriber, #15413) [Link]
The statement was clearly that windows would get the positioning confused. Perhaps you're laboring under the misconception that everyone puts the close box in the same place? (This is false, by the way).
From where I sit, nearly every prefab environments gets the window decorations quite wrong, by putting destructive, unrecoverable decoration buttons directly adjacent to nondestructive, recoverable buttons.
For example, nearly everyone puts close adjacent to things like minimize, so an attempted minimize can lose your work.
I'm certainly not going to accept an environment that allows the app developer to inflict this kind of stupidity on me.
LFCS 2012: X and Wayland
Posted Apr 14, 2012 2:55 UTC (Sat) by quintesse (subscriber, #14569) [Link]
LFCS 2012: X and Wayland
Posted Apr 14, 2012 13:01 UTC (Sat) by jospoortvliet (subscriber, #33164) [Link]
LFCS 2012: X and Wayland
Posted Apr 14, 2012 13:22 UTC (Sat) by quintesse (subscriber, #14569) [Link]
People come up with red herrings of things that will surely happen if we allow CSD while ignoring the facts that show that on other OSes they seem to be doing fine, no complete chaos of every app for himself and just drawing the decorations however they feel like (and examples that if an app really wants they can break the rules even on X, ie Chrome).
Apps built on top of the software made by their respective DEs won't even know anything changed, the core software in Gnome and KDE will take over the rendering of the decorations. So in one fell swoop a large quantity of apps will behave exactly as before.
Most other apps will not go through the trouble of rendering their own decoration either and will use some kind of system service/library for that (probably the same Gnome and KDE will be using).
So that only leaves us with those apps that decide to do their own rendering for some reason and that's when we have to remember that Linux/BSD are highly managed environments where apps that misbehave will probably get fixed or ignored.
And that's why I think CSD is not the end of the world.
LFCS 2012: X and Wayland
Posted Apr 14, 2012 15:49 UTC (Sat) by apoelstra (subscriber, #75205) [Link]
How will any of these know if I don't want -any- decorations, just a 10px title bar with a title on it?
These "other OSes" you claim are working fine, are so inflexible, and have such insane defaults (which for the most part cannot be changed) that they are nearly unusable to me. This is hardly what I call "working fine". Not to mention the insanity individual apps can, and do, foist on the system..
LFCS 2012: X and Wayland
Posted Apr 14, 2012 16:11 UTC (Sat) by quintesse (subscriber, #14569) [Link]
Yes those other OSes or less flexible, what does that have to do with anything? We were talking about being able to provide a consistent desktop experience, even when using CSD. And talk about insanity, you *really* want to use the Linux desktop as an example of saneness???
LFCS 2012: X and Wayland
Posted Apr 16, 2012 18:43 UTC (Mon) by sorpigal (subscriber, #36106) [Link]
Putting window controls outside of the application is one of the things that the Linux desktop does which is undeniably better than the alternatives. Why do you want to throw away an advantage? You seem to be assuming that the way things work is "just" an accidental side effect of the implementation and not, as it is, a feature.
The correct thing to do is to find a way to retain the experience we have now--which is well liked--and add technically superior underpinnings. So far I have heard that Wayland will throw away valuable and desirable features with the only justification given as "We want to improve the implementation and it's too hard to make it keep working the right way afterwards, so we decided to assume that no one cares."
If the new system really is superior then re-implement the old system on top; if you can't, it isn't.
LFCS 2012: X and Wayland
Posted Apr 16, 2012 21:48 UTC (Mon) by quintesse (subscriber, #14569) [Link]
We already know that X is better at handling unresponsive apps, but that's not something that's impossible to do with CSD.
So what else is so superior that people will not even wait until Wayland has actually something usable to show to before running it into the ground? (which is by the way the ONLY thing I've been trying to clear up all this time. Of course if Wayland can maintain current X functionality I'll be happy, but I'm just not convinced I'll be unhappy if they can't)
LFCS 2012: X and Wayland
Posted Apr 17, 2012 11:55 UTC (Tue) by sorpigal (subscriber, #36106) [Link]
LFCS 2012: X and Wayland
Posted Apr 17, 2012 12:04 UTC (Tue) by quintesse (subscriber, #14569) [Link]
LFCS 2012: X and Wayland
Posted Apr 17, 2012 19:09 UTC (Tue) by raven667 (subscriber, #5198) [Link]
LFCS 2012: X and Wayland
Posted Apr 18, 2012 8:12 UTC (Wed) by renox (subscriber, #23785) [Link]
Except of course that the same people at different times may do totally different things due to changing priorities, which means you have _no_point_.
LFCS 2012: X and Wayland
Posted Apr 19, 2012 18:46 UTC (Thu) by tuna (guest, #44480) [Link]
LFCS 2012: X and Wayland
Posted Apr 14, 2012 16:45 UTC (Sat) by mpr22 (guest, #60784) [Link]
Individual apps already can "foist insanity" on X desktops. My current choice of audio playback application (they're all crap one way or another, this one happens to annoy me less than most) comes up with its own close/minimize buttons and no WM-applied decorations.
LFCS 2012: X and Wayland
Posted Apr 15, 2012 16:46 UTC (Sun) by Tet (subscriber, #5433) [Link]
People come up with red herrings of things that will surely happen if we allow CSD while ignoring the facts that show that on other OSes they seem to be doing fineI'm somewhat staggered by this comment. I don't know which world you live in, but it doesn't seem to be the same one as me. I can't speak about OS X, but client side window decoration causes massive problems on Windows in the real world. Further, the very concept seems fundamentally flawed because it assumes that all applications will be written using an appropriate toolkit, which just plain isn't true. It isn't true now, it hasn't been true for the last 30 years, and it won't be true in the future. Unlike many X fans, I'm not opposed to Wayland. But I'm very strongly opposed to the way it's going about some things. Notably removing my control over my environment.
LFCS 2012: X and Wayland
Posted Apr 15, 2012 17:11 UTC (Sun) by quintesse (subscriber, #14569) [Link]
But of course, according to you that can't really be true because they have "massive problems". Really now?
LFCS 2012: X and Wayland
Posted Apr 15, 2012 20:42 UTC (Sun) by Tet (subscriber, #5433) [Link]
LFCS 2012: X and Wayland
Posted Apr 15, 2012 21:18 UTC (Sun) by quintesse (subscriber, #14569) [Link]
Oh and wait, in Windows 7 I actually *can* do it, seems that MS after many many years finally fixed that one.
But the people working on Wayland have said they've already thought about possible solutions to these problems. So why not wait and see what happens?
And if we have to talk about the lowering of expectations, I've been a Linux user for many years and if it has taught me anything it is not to have too many expectations and lots of patience.
LFCS 2012: X and Wayland
Posted Apr 16, 2012 23:15 UTC (Mon) by BenHutchings (subscriber, #37955) [Link]
Windows had the compatibility problem that the window manager used to be just a library that would run in the client processes. While most clients would just pass mouse clicks on the decorations into the default message handler, some of them relied on being notified in advance of any change to their window and being able to override it. Changing that ran the risk of breaking applications.
X applications don't assume they can have this control, and Wayland application won't be able to do so either. Being responsible for rendering decorations doesn't mean becoming the window manager, though certainly lack of visible feedback to window decorations is a pain.
LFCS 2012: X and Wayland
Posted Apr 11, 2012 20:26 UTC (Wed) by NAR (subscriber, #1313) [Link]
How long will it be before there are apps where the 'close' button on the window actually does something else?If I remember correctly, I can setup a handler in Java for the "window close button clicked" event, i.e. the application can do whatever it wants to do for over 15 years.
LFCS 2012: X and Wayland
Posted Apr 12, 2012 5:41 UTC (Thu) by Tuna-Fish (guest, #61751) [Link]
About -25 years or so. Doing this is entirely possible at present, and part of normal functionality for a lot of applications. For example, when I "close" xchat, it actually minimizes into tray, because that's typically what I want it to do.
LFCS 2012: X and Wayland
Posted Apr 21, 2012 18:07 UTC (Sat) by JanC_ (subscriber, #34940) [Link]
LFCS 2012: X and Wayland
Posted Apr 11, 2012 20:04 UTC (Wed) by marduk (subscriber, #3831) [Link]
OTOH I don't use *that* many apps not built around my desktop environment/X11 toolkit. The ones I do use already look/feel different, so adding window decoration into the mix isn't going to peeve me much more than it already does.
LFCS 2012: X and Wayland
Posted Apr 11, 2012 20:10 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]
LFCS 2012: X and Wayland
Posted Apr 11, 2012 20:05 UTC (Wed) by JoeBuck (subscriber, #2330) [Link]
My guess is that by the time this is deployed, you'd have KDE and Gnome applications that speak Wayland, and use common theming to get consistent decorations, together with legacy apps that speak X, run on the Wayland/X server, and have their decorations drawn by the Wayland/X window manager, again according to the common theme.Perhaps a Wayland expert can elaborate or tell us how it really should be done.
LFCS 2012: X and Wayland
Posted Apr 12, 2012 0:19 UTC (Thu) by dgm (subscriber, #49227) [Link]
LFCS 2012: X and Wayland
Posted Apr 12, 2012 14:03 UTC (Thu) by glandium (subscriber, #46059) [Link]
LFCS 2012: X and Wayland
Posted Apr 12, 2012 14:29 UTC (Thu) by dgm (subscriber, #49227) [Link]
LFCS 2012: X and Wayland
Posted Apr 12, 2012 21:41 UTC (Thu) by glandium (subscriber, #46059) [Link]
LFCS 2012: X and Wayland
Posted Apr 13, 2012 9:29 UTC (Fri) by dgm (subscriber, #49227) [Link]
LFCS 2012: X and Wayland
Posted Apr 15, 2012 18:06 UTC (Sun) by glandium (subscriber, #46059) [Link]
LFCS 2012: X and Wayland
Posted Apr 16, 2012 11:28 UTC (Mon) by nix (subscriber, #2304) [Link]
But, noooo, it's better to force people to reimplement or fork the whole thing! Bah.
LFCS 2012: X and Wayland
Posted Apr 13, 2012 0:24 UTC (Fri) by robert_s (subscriber, #42402) [Link]
But is there no way of _forcing_ an application to use a users preferred decoration/manager?
LFCS 2012: X and Wayland
Posted Apr 13, 2012 5:21 UTC (Fri) by renox (subscriber, #23785) [Link]
Look, most applications will use a toolkit, the toolkit will use a common way to draw the decorations (otherwise there will be a coherency issue), ideally a shared library.
This library will draw the decoration according to users preference and it must be very flexible, it's even planned for KDE to use *server side decoration* if I understand their plan well.
But no, there is no way to force an application (short of modifying it) to use all this, and *this is not an issue* because there are *now* lots of way for an application to misbehave but in practice this doesn't happen.
LFCS 2012: X and Wayland
Posted Apr 13, 2012 11:24 UTC (Fri) by jengelh (guest, #33263) [Link]
It's not about those that do, but about those which don't. Even if Qt and GTK start drawing the deco, there is still SDL and glut, for example.
LFCS 2012: X and Wayland
Posted Apr 13, 2012 11:39 UTC (Fri) by renox (subscriber, #23785) [Link]
LFCS 2012: X and Wayland
Posted Apr 13, 2012 5:31 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]
However, you can set the default decorations to empty rectangles and have your compositor to draw whatever decorations it wants to do. Some applications might ignore the setting and do whatever they want, but that's how they behave right now anyway.
Additionally, you can do tricks like overlaying a gray rectangle over an unresponsive application and drawing large "KILL" button on it to immediately kill the hung application.
LFCS 2012: X and Wayland
Posted Apr 13, 2012 9:47 UTC (Fri) by dgm (subscriber, #49227) [Link]
But you can always try embarrassing the developer in public for not doing things the right way :-)
LFCS 2012: X and Wayland
Posted Apr 12, 2012 14:58 UTC (Thu) by randomguy3 (guest, #71063) [Link]
There is the potential for clients with no decorations at all on Weston, or clients with two lots of decorations on KWin.
LFCS 2012: X and Wayland
Posted Apr 13, 2012 6:30 UTC (Fri) by alison (subscriber, #63752) [Link]
-- Alison, who's looking forward to test-driving Wayland
LFCS 2012: X and Wayland
Posted Apr 13, 2012 11:10 UTC (Fri) by mgraesslin (subscriber, #78959) [Link]
We will most likely go for an approach were all Wayland Clients will be forced into server side decorations no matter whether they use Client Side Decorations or not. We have to do that as the differentiation between our Workspaces (Desktop, Netbook, Tablet) is from Window Manager perspective mostly in the decorations (Desktop always decoration, Netbook decorated except maximized windows, Tablet undecorated). I don't expect that application developers will care about such differentiation and we need to have the possibility to experiment in that area. We would limit ourselves if we would allow Client Side Decorations.
I have even considered to enforce server side decorations on X11 but that's difficult due to backwards compatibility.
LFCS 2012: X and Wayland
Posted Apr 13, 2012 12:07 UTC (Fri) by HelloWorld (guest, #56129) [Link]
LFCS 2012: X and Wayland
Posted Apr 13, 2012 13:03 UTC (Fri) by mgraesslin (subscriber, #78959) [Link]
Sorry a library just does not fit it. Especially not if we want to be able to experiment from one release to the other.
We just should not try to fix what is not broken and keep server side decorations. Please read http://blog.martin-graesslin.com/blog/2010/05/open-letter... why client side decorations are a very bad idea. And no, most of the issues mentioned in that blog post will not go away with Wayland. Some issues might be fixable by adding some glue there and some hacks there, but then we are again fixing what is not broken :-)
LFCS 2012: X and Wayland
Posted Apr 15, 2012 19:00 UTC (Sun) by The_Barbarian (subscriber, #48152) [Link]
How about running untrusted applications?
Posted Apr 24, 2012 11:44 UTC (Tue) by gmatht (subscriber, #58961) [Link]
There has been research into secure GUIs which minimize an applications ability to interfere with other applications running on the same screen, with some attempts to retrofit this to UNIX. For example the Plash Powerbox uses preload tricks to transparently replace the GTK file open dialog box with a powerbox that hands back the right to open the file the user has chosen (but none of the users other files which are otherwise inaccessible due to chroot trickery).
Unfortunately X isn't especially well prepared to deal with hostile clients. Potentially a simpler and more modern system could be more secure. It seems to me that if the clients are responsible for drawing their own decorations that would instead make a secure GUI harder. The secure GUIs rely on, for example, windows titles being correct even in the case of a hostile client. This would seem hard to ensure if the API encouraged applications to draw their own decorations.
How about running untrusted applications?
Posted Apr 24, 2012 13:51 UTC (Tue) by dgm (subscriber, #49227) [Link]
A very poor assumption, if you ask me.
How about running untrusted applications?
Posted Apr 24, 2012 14:15 UTC (Tue) by renox (subscriber, #23785) [Link]
Uh? If the window manager is in the server, that's not such a bad assumption!
For example you can divide your applications into trusted and untrusted one, the window tittle being very different in both cases..
With CSD, obviously you can't do this.
How about running untrusted applications?
Posted Apr 24, 2012 16:11 UTC (Tue) by dgm (subscriber, #49227) [Link]
How about running untrusted applications?
Posted Apr 24, 2012 16:32 UTC (Tue) by renox (subscriber, #23785) [Link]
Of course they are, but this doesn't mean that a window manager cannot get its own way to check whether the application is trusted or not (not so simple in practive but doable I think) and display a trust indicator next to the window tittle.
Not sure what you mean about your point 2, but clearly untrusted applications must be restricted in what they're allowed to do (no real fullscreen, no input redirection, etc).
> 3. Aren't server side decorations something exclusive of X? meaning that applications relying on this would not be portable to Windows or OSX?
Portable applications exist already today with X and Windows/OS X, so I'm not sure what is your point.
LFCS 2012: X and Wayland
Posted Apr 11, 2012 19:40 UTC (Wed) by glandium (subscriber, #46059) [Link]
LFCS 2012: X and Wayland
Posted Apr 11, 2012 20:01 UTC (Wed) by JoeBuck (subscriber, #2330) [Link]
Window manager variety
Posted Apr 11, 2012 20:12 UTC (Wed) by rfunk (subscriber, #4054) [Link]
Window manager variety
Posted Apr 11, 2012 20:21 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]
Window manager variety
Posted Apr 18, 2012 14:02 UTC (Wed) by gmaxwell (guest, #30048) [Link]
No— the distros will just package this stuff, and eventually all distro users will simply be forced to use it, since the packaged software will stop working with classic X11 and the whole reason you were running a distro in the first place was to outsource the distro maintaining to someone else.
Window manager variety
Posted Apr 11, 2012 21:35 UTC (Wed) by raven667 (subscriber, #5198) [Link]
Window manager variety
Posted Apr 11, 2012 21:40 UTC (Wed) by alankila (subscriber, #47141) [Link]
Window manager variety
Posted Apr 11, 2012 22:00 UTC (Wed) by apoelstra (subscriber, #75205) [Link]
Would you like a window manager with 10-pixel-high title bars, which automatically positions windows in a tiled layout, which can be rearranged using the vi keys?
Perhaps you would. I wouldn't have it any other way.
But given the relative popularity of metacity and kwin, I suspect that most people would disagree -- and that is why we have 20 different window managers. Because nobody agrees on what "good" even means, let alone "good enough".
Window manager variety
Posted Apr 11, 2012 22:12 UTC (Wed) by fluxion (subscriber, #62978) [Link]
Window manager variety
Posted Apr 12, 2012 5:33 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
Window manager variety
Posted Apr 12, 2012 12:06 UTC (Thu) by sorpigal (subscriber, #36106) [Link]
Window manager variety
Posted Apr 12, 2012 16:11 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
It's simply that nobody cares much. I've seen a tiled window manager for Windows, btw.
Window manager variety
Posted Apr 12, 2012 14:31 UTC (Thu) by alankila (subscriber, #47141) [Link]
Window manager variety
Posted Apr 27, 2012 5:58 UTC (Fri) by Duncan (guest, #6647) [Link]
FWIW, my kde is highly customized as a sort-of hybrid tiling/floating mixture, with floating dominating, but various windows configured to specific sizes and/or locations, including two dominant themes of maxed-Y/half-maxed-X for side-by-side for things like browsers and terminal windows, and maxed-X/almost-maxed-Y, lacking only titlebar height (and sometimes no-border so I get full app height as if it had the titlebar anyway), for things like tri-pane mail, news and feed-reader clients. Combined with (sloppy) focus follows mouse, click-to-raise and with semi-transparent inactive, that lets me work with either the two side-by-side windows or with the almost-maxed and a half-maxed window concurrently, or with all three windows, the back half-maxed one viewable when focused (but not raised) thru the semi-transparent inactive almost-maxed window above it.
It sounds horrible I know, but there's a productive workflow there that I've grown to depend on, and I was VERY unhappy when an earlier version of it broke with my transfer from kde3 to supposedly ready but still in reality VERY early alpha quality kde4. Fortunately I was able to work around or find alternate solutions for the broken bits, and kde4 itself has improved dramatically since then, such that at least with semantic-desktop not only turned off but actually compiled out (gentoo, USE=-semantic-desktop), I can honestly say I'm enjoying kde4 as much if not more than I did late kde3, now.
Window manager variety
Posted Apr 12, 2012 0:16 UTC (Thu) by nybble41 (subscriber, #55106) [Link]
Anyway, there is no such thing as a single "good enough" window manager, or any other program for that matter. Different people have different requirements, which in turn demand different solutions.
Window manager variety
Posted Apr 12, 2012 6:46 UTC (Thu) by niner (subscriber, #26151) [Link]
Things we would lose are having extremely lightweight window managers and the choice about the programming language it's implemented in. Personally I don't think that the first one is really a loss. Window management is no performance critical task and I guess that even a completely new behavior would be just a couple of 100 lines of code. A device which is able to handle a graphical UI would already have enough memory that this doesn't matter at all.
Window manager variety
Posted Apr 12, 2012 7:33 UTC (Thu) by daniels (subscriber, #16193) [Link]
IMHO, it's a bit hypocritical for a Linux user to argue against the possibility of multiple, competing alternatives.
Window manager variety
Posted Apr 12, 2012 15:31 UTC (Thu) by nybble41 (subscriber, #55106) [Link]
However, were it not for the freedom to make unpopular choices, including the choice to develop an alternative to an existing "good enough" solution, we wouldn't have Linux in the first place. Anyone who works on Linux is already exercising that freedom, which makes it hypocritical to talk about denying the same freedom to others.
Window manager variety
Posted Apr 12, 2012 15:40 UTC (Thu) by daniels (subscriber, #16193) [Link]
However, were it not for the freedom to make unpopular choices, including the choice to develop an alternative to an existing "good enough" solution, we wouldn't have Linux in the first place. Anyone who works on Linux is already exercising that freedom, which makes it hypocritical to talk about denying the same freedom to others.
Yes, it would be if anyone had said that, but you're arguing against a strawman. Anyone who wants to work on an alternative desktop environment is more than free to do so; no-one is denying them that right. However, it doesn't mean that everyone around them has to care about it, and/or pander to their needs, requests, and demands of other projects.
Window manager variety
Posted Apr 12, 2012 16:28 UTC (Thu) by nybble41 (subscriber, #55106) [Link]
> Yes, it would be if anyone had said that, but you're arguing against a strawman. Anyone who wants to work on an alternative desktop environment is more than free to do so; no-one is denying them that right.
Sure, it's not literally _denying_ the freedom to work on alternatives--that was a bit of justifiable hyperbole on my part--but the original comment was clearly disparaging the idea of developers working on anything but the "1 good enough" solution, which, if consistently applied, would include anyone working on Linux.
> However, it doesn't mean that everyone around them has to care about it, and/or pander to their needs, requests, and demands of other projects.
I agree completely. However, while we're on the subject of strawman arguments... who said anything about providing support? The original comment was simply about developing alternatives to Weston. No mention was made of any expectation of interest or "pandering" by others.
Window manager variety
Posted Apr 12, 2012 8:06 UTC (Thu) by Seegras (subscriber, #20463) [Link]
And not only that, different people have different hardware. On the desktop I use WindowMaker with sloppy focus and autoraise, because a) I've got the screen real-estate and b) a mouse. On my netbook, I'm running xfce with click-to-focus, because the screen is very small and usually there's no mouse attached. And on my phone, there's an entirely different window manager running -- I'd be very unhappy with xfce or WindowMaker there ;))
Window manager variety
Posted Apr 12, 2012 14:56 UTC (Thu) by alankila (subscriber, #47141) [Link]
It's also a valid point that a different hardware setup requires a different paradigm. Whether Weston can adapt to, say, mouseless and keyboardless window management is a separate question in itself, but at least different interface devices undeniably pose different requirements.
Window manager variety
Posted Apr 18, 2012 19:13 UTC (Wed) by kleptog (subscriber, #1183) [Link]
I'll admit that progress is not very fast, but there is progress.
Window manager variety
Posted Apr 18, 2012 22:33 UTC (Wed) by khim (subscriber, #9252) [Link]
Your definition of progress is kinda strange: tiling window managers were tried and explicitly rejected! And it happened decades ago! They were tried and rejected before X Window System was born!
Tiling window managers were invented before anything else: remember that both Xerox Star (in 1981, no less) and Windows 1.0 (in 1985) employed tiling window managers! They were neat, but people rejected them.
Today they are in position similar to other old rejected technologies (such as Acme or FFM): some old-timers still use them and even few newcomers are choosing them but most users don't know about them and don't want to know about them.
Window manager variety
Posted Apr 19, 2012 0:14 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
and therefor (according to you) such choices should be eliminated so that NOBODY is able to use them.
By that logic Linux itself should never have been created, the iPhone should never have been created, nothing new should ever be created because everyone is perfectly happy with what they have.
Window manager variety
Posted Apr 19, 2012 17:47 UTC (Thu) by khim (subscriber, #9252) [Link]
and therefor (according to you) such choices should be eliminated so that NOBODY is able to use them.
Probably. It really depends on the popularity of said things.
By that logic Linux itself should never have been created, the iPhone should never have been created, nothing new should ever be created because everyone is perfectly happy with what they have.
This is strange conclusion: we don't know if something will stick or not unless we'll try. Any new creation starts from one user and grows from there. Or not. If it becomes large enough then it gets enough resources to survive, if not then it's time to finish it.
Linux succeeded: it basically killed Unix and took it's niche, iPhone succeeded, too: it (along with Android) killed RIM and Symbian and took it's niche, webOS failed (and it's now time to write it off).
This is just a natural selection. It was not as troublesome 10, 20, or 100 years ago: markets grew, population grew, pool of knowledgeable workers grew, it was possible to keep both old and new things alive. Today… there are just not enough people to do that: if you want to continue to create something new then you must be ready to weed out something old, too.
Window manager variety
Posted Apr 19, 2012 13:14 UTC (Thu) by renox (subscriber, #23785) [Link]
Your own definition of progress is weird too..
At the time most users had small screen, so the situation is different now, plus small difference in implementation can make big difference in end-user acceptance.
And "progress" is not something predictable!
Window manager variety
Posted Apr 19, 2012 10:10 UTC (Thu) by mpr22 (guest, #60784) [Link]
I do not see how the "perfect size" for an arbitrary window can possibly be within the window manager's capability to determine, unless the display device is so pixel-limited that the only sane size for any window is "fullscreen".
Window manager variety
Posted Apr 20, 2012 8:56 UTC (Fri) by jezuch (subscriber, #52988) [Link]
Hmm, my only clue comes from Java's Swing UI toolkit, where everything is a tree of nested components, each component having a "minimal" and "preferred" sizes. The containers derive their minimal and preferred sizes from the contained components and the layout manager in use. There is even an operation called "pack" that resizes the window according to the preferred sizes of its components. A tiling manager could use this information but it required cooperation from the toolkit.
Window manager variety
Posted Apr 20, 2012 17:40 UTC (Fri) by apoelstra (subscriber, #75205) [Link]
>Hmm, my only clue comes from Java's Swing UI toolkit, where everything is a tree of nested components, each component having a "minimal" and "preferred" sizes. The containers derive their minimal and preferred sizes from the contained components and the layout manager in use. There is even an operation called "pack" that resizes the window according to the preferred sizes of its components. A tiling manager could use this information but it required cooperation from the toolkit.
So the "perfect size" is determined by the application developer? No thanks.
Window manager variety
Posted Apr 21, 2012 20:47 UTC (Sat) by kleptog (subscriber, #1183) [Link]
That said, I didn't realise the tiling window manager was such an old concept. I hadn't seen it before though, I certainly haven't managed to get my default Ubuntu install to do it.
Window manager variety
Posted Apr 21, 2012 21:14 UTC (Sat) by khim (subscriber, #9252) [Link]
That said, I didn't realise the tiling window manager was such an old concept.
Well, as I've said not only they are old, they were explicitly rejected. Windows developers apparently liked them (as you do) and though it'll be Windows advantage. Ha! The supposed “inability to create overlapped windows” was one of the more frequent complaints about Windows 1.0. It's obvious for the programmer that it was made explicitly (you had the ability to create and use any number of overlapping dialog windows in Windows 1.0, after all) but Joe Average (including Joe Magazine Observer Average) was quite literally unable to even imagine that someone will create something like this intentionally!
Of course the concept was quickly buried never to be seen on mainstream system again.
Window manager variety
Posted Apr 21, 2012 21:30 UTC (Sat) by dlang (✭ supporter ✭, #313) [Link]
In the case of tiling window managers, one thing to remember is that the screen resolution when they were 'explicitly rejected' for windows 1.0 was 640x400, screens are a bit bigger today, so things that wouldn't work then can work now.
Also, you need to break your mindset that Microsoft is the ultimate authority on the Right Way to do everything
Window manager variety
Posted Apr 21, 2012 23:12 UTC (Sat) by khim (subscriber, #9252) [Link]
there are a lot of things that have been 'explicity rejected' by people in the past that are in common use today. It's not unusual for other things to change that make something that used to not be reasonable now become reasonable.
Sure. But before you'll try to resurrect some old concept you need to find out why it failed in the past. If it's some technical limitation then it may be overcome, if it's something psychological then situation is much harder.
For example a lot of guys present iPhone (or sometimes iPad) as reincarnation of Newton, and yes, the devices look similar. But the difference is extreme: Newton was built around the handwriting recognition. It was it's cornerstone, everything else was built around this idea. And it just so happen that this idea does not work. iPhone/iPad looks similar, but they don't include stylus and don't use handwriting recognition. At all. You can as well say that contemporary planes are just a reimplementation of the Daedalus creation.
In the case of tiling window managers, one thing to remember is that the screen resolution when they were 'explicitly rejected' for windows 1.0 was 640x400, screens are a bit bigger today, so things that wouldn't work then can work now.
Perhaps, but I seriously doubt it. The biggest problem with tiling managers is perception of the lost control. People want to control their windows, not have them arranged automatically. Perhaps it's possible to create tiling manager which will feel natural, but I'm not holding my breath.
Also, you need to break your mindset that Microsoft is the ultimate authority on the Right Way to do everything.
Of course not! Microsoft is not perfect, but Microsoft is what people use. For better or for worse Windows defines expectations - simply because it's the most popular UI.
Even so… Microsoft tries very hard to destroy itself for the last five years or so. People hated (and still hate) their Ribbon - but apparently not enough to switch to something else. Perhaps Metro will finally push them over the edge?
This gives newcomes a chance. But I doubt something as radically different as tiling WM will be accepted by Joe Average even in the wake of Metro fisco.
Window manager variety
Posted Apr 22, 2012 0:46 UTC (Sun) by dlang (✭ supporter ✭, #313) [Link]
you are looking at things backwards.
If the talk about tiling window managers was only from people creating them, saying "this is what people should use" (the type of talk you see coming out of the Gnome or Unity projects for example), then you would have good reasons to point out past attempts and say "No, people don't really want that, here's why"
But when the statements are from people who are using a tiling window manager saying "It's the best thign I've ever used", then you should just shut up because otherwise you are telling people "no, you don't really like what you think you like"
As for Microsoft, If you really like what they do so much, go use it and let those of us who want some variation use what we want. We are used to having features as default (a desktop pager for example) that just aren't available (or only available via a third party hack) on Microsoft desktops.
The great thing is that on Linux, we don't force everyone to use the same thing. Even the distros that have a primary default allow you to switch to one of the other options (and in some cases, like Kubuntu, it's only barely a second class option)
Window manager variety
Posted Apr 22, 2012 11:40 UTC (Sun) by khim (subscriber, #9252) [Link]
But when the statements are from people who are using a tiling window manager saying "It's the best thign I've ever used", then you should just shut up because otherwise you are telling people "no, you don't really like what you think you like"
Nice strawman. I said, quite literally: the concept was quickly buried never to be seen on mainstream system again and today they are in position similar to other old rejected technologies (such as Acme or FFM): some old-timers still use them and even few newcomers are choosing them but most users don't know about them and don't want to know about them.
How exactly this went from this to "no, you don't really like what you think you like" I'll never understand. It's quite obvious that I'm not talking about individual preferences here.
We are used to having features as default (a desktop pager for example) that just aren't available (or only available via a third party hack) on Microsoft desktops.
Right. But mindshare of people like you is shrinking and it's not clear where is the natural limit of this shrinkage. If some tools are only used by people in some small group then it may find out few years down the road that they just don't have the hardware they need and they can't run the software they want (while staying compatible with the rest of the world). History is littered by examples: Lisp machines (they were all the rage back in the day), RiscOS (ARM is quite popular today and you can even run RiscOS today on PandaBoard… but how many former RiscOS users actually do that?), Amiga ST, Atari, etc.
The great thing is that on Linux, we don't force everyone to use the same thing. Even the distros that have a primary default allow you to switch to one of the other options (and in some cases, like Kubuntu, it's only barely a second class option)
This is greatest strength of Linux and also is greatest weakness. RiscOS fate looks more and more real as time goes on. There was time not so long ago when people used Linux en masses in the university. Today they use MacOS instead. Even if it does not have a tiling window manager.
Window manager variety
Posted Apr 22, 2012 17:02 UTC (Sun) by apoelstra (subscriber, #75205) [Link]
Tiling window managers have recently seen a spike in usage, due (I believe) to the sudden destruction of GNOME by folks like you, who argue "users don't want to know about that, so let's stop supporting it" and remove essential features.
There is no question that tiling window managers are more efficient. Nowadays the most common complaint about window management is that wide screens are too wide to read on, and it's a PITA to manually resize windows to look nice on them. So, in Windows 7 you can now drag windows to the sides of the screen, and they'll fill that half. So you can emulate tiling for its most common use case.
As for history, the furthest back I can remember tiling was in Windows 95. You could right-click on the title bar and click "tile". It was crap. Every window got roughly a square inch of screen space, you couldn't control which ones were visible, in what order, how much space to allocate. The default window decorations were still in place, and together they took up around half the screen area. So I wondered what the point of such a stupid feature was, and forgot about it until just now.
But nowadays, I have too much screen space for comfortable full-screen apps, no mouse (since this is a laptop), and I want my windows either 100% visible or 0%. So I've got a tiling window manager, and -now- I think it's the greatest thing since sliced bread. I've showed it off to many people, and they all thought it was very cool (though they were Windows users and didn't have the option to try for themselves). I have never heard of anyone saying they were crap, or restrictive, or useless, until you.
Window manager variety
Posted Apr 22, 2012 17:37 UTC (Sun) by kleptog (subscriber, #1183) [Link]
Fortunately things are not either/or. I have my xterms set to tile, because working with several machines at the same time it's useful to be able to see all the output next to each other at once, tabs just don't cut it. On the other hand, tiling makes less sense for the web browser or email. Hurray for configurability.
In my case since >80% of my windows are xterms it's more useful to have a tiling window manager that floats a few windows, than a floating window manager. But theoretically if a standard window manager had the option to enable tiling for a few applications you'd make 90% of tiling window manager users happy.
Judging by the comments on this thread though, I figure that's never going to happen.
BTW, there are tiling window managers for Windows, see the wikipedia article.
Window manager variety
Posted Apr 22, 2012 17:48 UTC (Sun) by rahulsundaram (subscriber, #21946) [Link]
Attributing to khim the decisions by GNOME developers is fair to neither since khim is not a GNOME developer and doesn't speak for them or even share their mindset in any real way.
"So, in Windows 7 you can now drag windows to the sides of the screen, and they'll fill that half. So you can emulate tiling for its most common use case."
Funny enough, so does GNOME which voids your earlier argument.
Window manager variety
Posted Apr 13, 2012 0:29 UTC (Fri) by robert_s (subscriber, #42402) [Link]
This is utter nonsense. This idea may fly on proprietary desktops where a certain behaviour/layout/theme is provided or mandated from above by "god", but this is a collaboratively developed free desktop where people are able to implement and their preferences more freely.
Window manager variety
Posted Apr 13, 2012 0:45 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]
Window manager variety
Posted May 10, 2012 15:53 UTC (Thu) by nye (guest, #51576) [Link]
No they don't. Metro could be disabled in the Developer Preview, but it can't in the Consumer Preview. It remains to be seen how the final release will work.
(I've been using Windows 8 for a couple of weeks now; in many ways it's a great improvement over previous versions, but the moment you have to interact with Metro it feels like you're on a truck that just hit a wall. It's a horrifying blunder; I can't believe they seriously thought they could release a new OS with changes like this after seeing how Vista was received.)
Window manager variety
Posted Apr 12, 2012 10:23 UTC (Thu) by cwng (guest, #74460) [Link]
the window managers/compositors in Mac/Win come with and are not designed to be replaced by the end user. It'd be interesting to see if anyone has tried.
Window manager variety
Posted Apr 12, 2012 11:23 UTC (Thu) by cortana (subscriber, #24596) [Link]
Window manager variety
Posted Apr 12, 2012 11:45 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
I distinctly remember being able to do things like collapsing windows to title bars by triple-clicking or adding extra buttons to window titlebars.
Window manager variety
Posted Apr 16, 2012 18:51 UTC (Mon) by sorpigal (subscriber, #36106) [Link]
WindowBlinds was not a replacement window manager for Windows. It merely did some hackery to change some of the look and some behaviors and it always ran on top of the existing WM. Think of it more like a very-heavy theme. In the end things like window lists, window position and stacking order were still the same. In addition, it was awfully slow and memory hungry.
LFCS 2012: X and Wayland
Posted Apr 11, 2012 20:43 UTC (Wed) by drag (subscriber, #31333) [Link]
I posted it in a previous article comments thread touching on this subject:
http://wayland.freedesktop.org/faq.html#heading_toc_j_11
> 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.
However I am thinking that a superior approach would be to follow the Gnome Shell model of "Window Managing" and use a solid base of functionality and make it's behavior scriptable and extendable. The Shell Window manager is built on Metacity, which is a very mature simplistic window manager. But using that base and it's javascript nature I can have a tiling window manager without actually have to swap out window managers completely. (which I do tile windows on Gnome-shell via gtile)
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.
LFCS 2012: X and Wayland
Posted Apr 12, 2012 19:43 UTC (Thu) by Fats (subscriber, #14882) [Link]
> 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,
Staf.
LFCS 2012: X and Wayland
Posted Apr 13, 2012 0:53 UTC (Fri) by hholzgra (subscriber, #11737) [Link]
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 (guest, #137) [Link]
LFCS 2012: X and Wayland
Posted Apr 20, 2012 11:44 UTC (Fri) by dgm (subscriber, #49227) [Link]
With X11 you currently have 3 processes:
1. X server
2. X client
3. compositor/window manager
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]
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]
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]
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]
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.
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.
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]
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.
Secondly I am waiting to see how network transparency will be implemented, vnc style remote usage won't cut it for me.
greets,
Staf.
LFCS 2012: X and Wayland
Posted Apr 14, 2012 9:24 UTC (Sat) by renox (subscriber, #23785) [Link]
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]
LFCS 2012: X and Wayland
Posted Apr 15, 2012 9:27 UTC (Sun) by renox (subscriber, #23785) [Link]
LFCS 2012: X and Wayland
Posted Apr 19, 2012 21:25 UTC (Thu) by wmf (guest, #33791) [Link]
LFCS 2012: X and Wayland
Posted Apr 19, 2012 22:00 UTC (Thu) by nybble41 (subscriber, #55106) [Link]
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]
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]
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:
- the stock server (Weston) doesn't know when a user moves/resizes a window until the client tells it, so there must be a round trip before any action happen: far from ideal in a WAN.
- 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]
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:
-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.
-Also an X client can send an image of each letter only once on the server, cache it there, and then reuse it: very efficient in terms of bandwith usage, but currently Wayland don't provide this and as nybble41 said, it would be a big change to add a remote rendering protocol.
LFCS 2012: X and Wayland
Posted Apr 20, 2012 9:56 UTC (Fri) by cortana (subscriber, #24596) [Link]
LFCS 2012: X and Wayland
Posted Apr 20, 2012 11:45 UTC (Fri) by renox (subscriber, #23785) [Link]
LFCS 2012: X and Wayland
Posted Apr 20, 2012 12:04 UTC (Fri) by chris.wilson (subscriber, #42619) [Link]
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]
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]
>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.
> 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.
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]
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]
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]
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]
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]
>"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:
1) A window grays out.
2) "Force Close" and "Hide" buttons appear
3) You press "Hide" button and window disappears.
4) An icon in the system notification area appears notifying you that there are unresponsive applications. You can right-click on it and bring up a list of forcibly closed apps, with possibility to unhide or kill them.
5) If application recovers, then the user can be notified by flashing icon on the notification area.
Something like this.
LFCS 2012: X and Wayland
Posted Apr 17, 2012 17:21 UTC (Tue) by Fats (subscriber, #14882) [Link]
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]
LFCS 2012: X and Wayland
Posted Apr 17, 2012 19:07 UTC (Tue) by Fats (subscriber, #14882) [Link]
LFCS 2012: X and Wayland
Posted Apr 17, 2012 19:16 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]
LFCS 2012: X and Wayland
Posted Apr 13, 2012 12:13 UTC (Fri) by HelloWorld (guest, #56129) [Link]
LFCS 2012: X and Wayland
Posted Apr 13, 2012 16:21 UTC (Fri) by alankila (subscriber, #47141) [Link]
LFCS 2012: X and Wayland
Posted Apr 17, 2012 17:24 UTC (Tue) by Fats (subscriber, #14882) [Link]
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.
Not all gain
Posted Apr 11, 2012 20:35 UTC (Wed) by renox (subscriber, #23785) [Link]
I wonder if the "ugly output" happens only with applications/toolkit slow to redraw a window or if this is not related?
Because Wayland will have also an issue with "slow to redraw windows": the resizing of the window will "stutter" i.e the size of the window won't follow the mouse smoothly..
I'm not sure that one is better than the other: the solution IMHO is to avoid slow redrawing with a per-window thread dedicated to the rendering like BeOS/Haiku does.
Not all gain
Posted Apr 11, 2012 21:57 UTC (Wed) by drag (subscriber, #31333) [Link]
Not all gain
Posted Apr 12, 2012 0:52 UTC (Thu) by dgm (subscriber, #49227) [Link]
Rendering in a thread doesn't make drawing code magically faster. It only solves the problem of the application missing the retrace deadline because it's busy doing actual work, at the price of doing less such work (the thread needs cycles to draw the window, too).
Not all gain
Posted Apr 12, 2012 5:38 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
I tried that some years ago. It looks extremely ugly.
It's much better to simply draw an empty overlay rectangle showing the future window's size.
Not all gain
Posted Apr 12, 2012 7:41 UTC (Thu) by renox (subscriber, #23785) [Link]
It depends: with client-side decoration only the client know that the mouse action is supposed to trigger a window resizing not the server.
But the client could tell the server: using two requests 'my future window size is X,Y' and 'the content is here' instead of one 'draw this buffer of size X,Y', so if the second request is slow to come then the server can do some corrective action as you say.
I don't know what is the current API (one or two request), I find it difficult to understand..
LFCS 2012: X and Wayland
Posted Apr 11, 2012 21:38 UTC (Wed) by job (subscriber, #670) [Link]
For example, X security leaves a lot to be desired from the setuid server to the all-or-nothing model where any app can be a keysniffer. It would be interesting to hear what is being done about this. Another example is the somewhat convoluted events model which long made it difficult to use multiple heads and multiple pointers. (And let's not even mention the screen lockers...)
I am one of those who actually uses X's features, but it's clearly crufty (in more ways than the above) and I think Wayland sounds like a solid base on top of which X can continue to evolve. The developers seem to understand the complexities involved and actually strive to make something simple. That can only be a good thing.
Is GL support coming?
Posted Apr 11, 2012 22:32 UTC (Wed) by HelloWorld (guest, #56129) [Link]
Is GL support coming?
Posted Apr 12, 2012 3:57 UTC (Thu) by JohnLenz (subscriber, #42089) [Link]
Is GL support coming?
Posted Apr 12, 2012 12:33 UTC (Thu) by HelloWorld (guest, #56129) [Link]
Is GL support coming?
Posted Apr 12, 2012 12:41 UTC (Thu) by HelloWorld (guest, #56129) [Link]
Do you have any sources to back up your claim that EGL can be used to create OpenGL contexts? Khronos.org also only mentions GLES and OpenVG contexts...
LFCS 2012: X and Wayland
Posted Apr 11, 2012 22:40 UTC (Wed) by mezcalero (guest, #45103) [Link]
LFCS 2012: X and Wayland
Posted Apr 11, 2012 23:24 UTC (Wed) by jake (editor, #205) [Link]
Or perhaps work with the X folks to find some alternative way? We do own the whole stack, as Keith points out, and systemd *seems* like the right place to do this kind of thing ...
jake
LFCS 2012: X and Wayland
Posted Apr 12, 2012 4:52 UTC (Thu) by slashdot (guest, #22014) [Link]
AFAIK right now Wayland requires EGL/Gallium/DRM drivers, which generally suck (or don't work at all) compared to the proprietary drivers for the latest hardware.
It might be possible to create a fake X server stub that can load the proprietary X drivers and allow to implement EGL over them, though.
LFCS 2012: X and Wayland
Posted Apr 12, 2012 17:08 UTC (Thu) by drag (subscriber, #31333) [Link]
It requires OpenGLES2 and EGL + a couple of EGL extensions.
> which generally suck (or don't work at all) compared to the proprietary drivers for the latest hardware.
Combining overly broad assumptions with incorrect statements amounts to borderline trolling. The only proprietary driver worth a damn is Nvidia and it supports the necessary APIs.
It would require minimal effort on Nvidia's part to support Wayland correctly. Probably much easier then trying to support differences in Linux and Xorg revisions.
LFCS 2012: X and Wayland
Posted Apr 20, 2012 10:32 UTC (Fri) by wookey (subscriber, #5501) [Link]
LFCS 2012: X and Wayland
Posted Apr 12, 2012 8:08 UTC (Thu) by magnus (subscriber, #34778) [Link]
The main advantage pointed out seems to be performance, so has anyone actually measured how large the performance improvements are compared to the existing X stack?
LFCS 2012: X and Wayland
Posted Apr 12, 2012 9:45 UTC (Thu) by renox (subscriber, #23785) [Link]
I see two (very small) benefits: resizing windows may be prettier, and you can use a rotated window as if it wasn't rotated (except that it will be ugly due to the lack of anti-aliasing).
> The main advantage pointed out seems to be performance
Where did you see this pointed out?
Me, I didn't see claim of performance gain by Wayland developers and in my understanding there should be little difference: Wayland is very similar to the X DRI2 extension, so if the toolkit you use take advantage of the X DRI2 extension, then there shouldn't not be much performance gain with Wayland: fewer IPC due to the merge of the window manager and the display server/compositor, but about the same way to use the GPU memory.
LFCS 2012: X and Wayland
Posted Apr 12, 2012 11:30 UTC (Thu) by renox (subscriber, #23785) [Link]
Wayland performance
Posted Apr 16, 2012 19:55 UTC (Mon) by rvfh (subscriber, #31018) [Link]
In the article.
Basically, X does some buffer copying, so if your screen is 1920x1080@60Hz and assuming 32-bit RGB, this means copying about 8MB every 16 ms, or 480 MB/s of traffic. That's for one copy only, of course.
Wayland will just allocate a buffer straight from the graphics stack (DRM) which will be filled by the application and rendered by the graphics card with zero-copy.
Wayland performance
Posted Apr 16, 2012 20:04 UTC (Mon) by dlang (✭ supporter ✭, #313) [Link]
Wayland performance
Posted Apr 16, 2012 20:33 UTC (Mon) by renox (subscriber, #23785) [Link]
Where in the article?
>Basically, X does some buffer copying,
Not with the DRI2 extension AFAIK: X allocates a buffer in the GPU video memory which can be used by a client without copying like Wayland (not 100% sure: DRI2's documentation is hard to read).
Wayland performance
Posted Apr 16, 2012 20:51 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]
Wayland performance
Posted Apr 17, 2012 17:15 UTC (Tue) by rvfh (subscriber, #31018) [Link]
Third paragraph:
> From an application's perspective, there aren't that many changes. It still talks to the server for geometry handling and still talks to the kernel or server to create its graphics. But the protocol is different, which will save a bunch of time, system complexity, and memory, Packard said.
> Not with the DRI2 extension AFAIK: X allocates a buffer in the GPU video memory which can be used by a client without copying like Wayland (not 100% sure: DRI2's documentation is hard to read).
I think you're right, though I am no expert in DRI (only coming these days on SoCs, after years of re-inventing the wheel.)
Wayland performance
Posted Apr 17, 2012 19:56 UTC (Tue) by renox (subscriber, #23785) [Link]
Wayland performance
Posted Apr 17, 2012 20:28 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]
At which point you might start thinking that it's easier to throw away X-server completely out of your core and instead relegate it to the status of ordinary application. That's what Wayland does.
Wayland performance
Posted Apr 27, 2012 7:16 UTC (Fri) by Duncan (guest, #6647) [Link]
And even where memory isn't a problem on today's multi-gig-memory machines, smaller code means more of it fits in caches closer to the processor, where it's MANY times more efficient to access and thus faster running! =:^)
Of course, the biggest benefit there will only happen once most/all normally running apps are wayland, not X. But with a 50:1 or even if wayland's code grows by 10X, a 5:1 size difference, it won't take replacing /much/ of that legacy X code with wayland, to break-even and start the reduction, even while the majority of apps are still X. So we may begin to see memory benefits sooner than one might have expected, even while most apps remain X.
Not that this will be the major benefit, but it's one of them.
I think the biggest user visible improvement will likely be in stability, tho. There's a LOT of legacy code in X, and thus a lot of dingy corners for bugs to lurk in. Additionally, wayland is designed from the ground up to current kernel driver and mode-setting reality, while that functionality has sort of been bolted on to X. The more "direct drive" nature of wayland as well as the vastly smaller code should make tracing and eliminating bugs FAR easlier, at least for the first half-decade or so. After that, I guess we'll have to see, as X really HAS been great at adapting to the changes underneath and around it, and for any replacement to last as X has for over three decades and continue functioning as well as X still does today, despite all that legacy, is going to be quite a challenge indeed, to match!
LFCS 2012: X and Wayland
Posted Apr 12, 2012 10:14 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
Existing X applications won't be affected. X is going to be supported for the foreseeable future.
LFCS 2012: X and Wayland
Posted Apr 12, 2012 12:53 UTC (Thu) by sorpigal (subscriber, #36106) [Link]
So, in other words, nothing the user will notice.
LFCS 2012: X and Wayland
Posted Apr 12, 2012 14:43 UTC (Thu) by raven667 (subscriber, #5198) [Link]
LFCS 2012: X and Wayland
Posted Apr 12, 2012 15:14 UTC (Thu) by tack (subscriber, #12542) [Link]
LFCS 2012: X and Wayland
Posted Apr 13, 2012 5:13 UTC (Fri) by renox (subscriber, #23785) [Link]
Why are there glitches in the case you describe?
If this is driver related, Wayland won't help..
LFCS 2012: X and Wayland
Posted Apr 12, 2012 15:15 UTC (Thu) by HelloWorld (guest, #56129) [Link]
LFCS 2012: X and Wayland
Posted Apr 12, 2012 21:10 UTC (Thu) by sorpigal (subscriber, #36106) [Link]
I'll go out on a limb and say that the things you notice most users wouldn't identify. At best after they have the new stack they might be able to say it "just seems nicer" - but only a few of them.
LFCS 2012: X and Wayland
Posted Apr 13, 2012 17:02 UTC (Fri) by drag (subscriber, #31333) [Link]
Back in the day when OS X was the only desktop to use composition people tended to always regard the OS X desktop as the 'most snappy' or 'best looking' desktop. They would then look at the Linux desktop and compare with that and talk about how slow it was all the time.
The difference is that without composition the Linux desktop would force a re-render of the the window being moved and any of the overlapping windows in order to display the window moving around. This caused a lot of re-rendering of windows and when Linux couldn't keep up with the movement you saw a lot of high cpu usage, tearing of windows, and badly/incorrectly rendered space on overlapping windows. With composition OS X just used the image buffer and didn't have to re-render anything.. also if it couldn't keep up with mouse movement the display just lagged in order to retain smooth movement.
Without the technological understanding it was impossible to understand why OS X behaved and looked so much better then Linux/X did. So they just say 'OS X is faster' and just assume that is a valid explanation.
One of the horrible little facts about life is that people will often form a very valid opinion about something, even though they lack the ability to explain how they came about that opinion. Then when you ask them to explain it then they will simply make something up as to not appear to be stupid, and it's often very wrong. What is worse is that If people expect that they need to explain their opinions they often unconsciously pick a opinion that is easier to explain away.
The moral of the story is that even if people are unable to discern and point out differences in how windows and displays are rendered they will still react to changes positively or negatively.
LFCS 2012: X and Wayland
Posted Apr 13, 2012 17:24 UTC (Fri) by raven667 (subscriber, #5198) [Link]
LFCS 2012: X and Wayland
Posted Apr 18, 2012 14:16 UTC (Wed) by gmaxwell (guest, #30048) [Link]
They seem to be saying that the compositor will be able to resize the windows without the applications intervention leading to super duper smoothness.
Er. No. Resizing the window is not resampling. The layout and text needs to be rerendered because it doesn't change size.
As far as I can tell the kind of resizing this will improve is just the snazzy graphical eyecandy stuff— which every serious user turns off simply because the animations add delay.
LFCS 2012: X and Wayland
Posted Apr 19, 2012 19:04 UTC (Thu) by tuna (guest, #44480) [Link]
What will happen if you have a 120 hz/fps monitor?
LFCS 2012: X and Wayland
Posted Apr 20, 2012 7:00 UTC (Fri) by raof (subscriber, #57409) [Link]
Copyright © 2012, Eklektix, Inc.
This article may be redistributed under the terms of the
Creative
Commons CC BY-SA 4.0 license
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds