| |||||||||||||
LFCS 2012: X and WaylandLFCS 2012: X and WaylandPosted Apr 12, 2012 8:08 UTC (Thu) by magnus (subscriber, #34778)Parent article: LFCS 2012: X and Wayland
A lot of the articles on Wayland talk about architecture and subsystems etc, but what are the end user benefits of this massive API change (except the indirect benefits of having happier developers)?
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?
(Log in to post comments)
LFCS 2012: X and Wayland Posted Apr 12, 2012 9:45 UTC (Thu) by renox (subscriber, #23785) [Link]
> what are the end user benefits of this massive API change (except the indirect benefits of having happier developers)?
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?
LFCS 2012: X and Wayland Posted Apr 12, 2012 11:30 UTC (Thu) by renox (subscriber, #23785) [Link]
Also you forgot to ask what might be the drawbacks of this change:
- moving windows could be less smooth: now it is the client which ask the server to move the window before it could be done entirely in the window manager. - same thing with resizing window: there is a tradeoff between 'each frame is perfect' and 'smooth resizing' and I believe that Wayland went the 'each frame is perfect' way, so in some case the resizing may get jerky. - it will take some time between an application crash and Wayland detects it, in the meantime the window will be unresponsive. - if there is a new toolkit which provides only Wayland support, it won't have network transparency currently, it may get LAN transparency in the future (sending bitmaps of the window) but it is not sure that this will be usable for WAN: I believe that client side decoration increases the number of round trip between the server and the client.
Wayland performance Posted Apr 16, 2012 19:55 UTC (Mon) by rvfh (subscriber, #31018) [Link]
> Where did you see this pointed out?
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]
you only copy the entire screen if you are updating the entire screen at 60Hz (which you probably are not doing)
Wayland performance Posted Apr 16, 2012 20:33 UTC (Mon) by renox (subscriber, #23785) [Link]
>> Where did you see this pointed out?
> >In the article.
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]
X now uses texture_from_pixmap extension to transparently (for applications) move pixmaps into GPU. But it's not entirely transparent, so we get ugly tearing in video and overhead of compositing is noticeable.
Wayland performance Posted Apr 17, 2012 17:15 UTC (Tue) by rvfh (subscriber, #31018) [Link]
> Where in the article?
Third paragraph:
> 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]
Thanks for the indication of the paragraph, I think what he's talking about is that Weston integrates the window manager (well a part), the display server and the compositor so there will be less IPC so it's more efficient from this point of view, AFAIK nothing prevents an X server to be implemented in the same way if this is really a big performance improvement..
Wayland performance Posted Apr 17, 2012 20:28 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]
It means getting rid of X window manager as a separate entity and embedding it into the X-server process.
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]
Also from the article, current (tho incomplete) wayland code is ~10KLines, xorg is half a million. Now surely the klines of wayland code will increase, but a lot of that xorg code is legacy stuff that (approximately) no one uses any more. So even allowing for a 10X increase in lines of code (the first 90% of the implementation's only 10% of the code, or 80/20, or whatever), wayland should still be far smaller, thus being far more memory efficient.
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]
1) Every frame is perfect (Every frame is great). I.e. tear-free compositing in all cases.
2) Vast simplification of the whole system, including ability to run as a non-root user. 3) Potential to unify desktop and mobile graphics stacks (Android people as hell don't want to run X-server). 4) Fixing some old-standing X deficiencies.
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]
That's probably the idea. No serious regressions and a more streamlined and quicker to develop and easier to understand stack that will probably end up more reliable and faster as well.
LFCS 2012: X and Wayland Posted Apr 12, 2012 15:14 UTC (Thu) by tack (subscriber, #12542) [Link]
This user will sure notice being able to do smooth video playback with compositing enabled. In X today, this is the source of many glitches (missed retraces, or worse).
LFCS 2012: X and Wayland Posted Apr 13, 2012 5:13 UTC (Fri) by renox (subscriber, #23785) [Link]
Hum, don't mistake Wayland for a cure of all the issue..
Why are there glitches in the case you describe?
LFCS 2012: X and Wayland Posted Apr 12, 2012 15:15 UTC (Thu) by HelloWorld (guest, #56129) [Link]
I notice all kinds of artifacts all the time on my Linux Desktop. "Every frame is perfect" is definitely something that needs to be worked on, and I'm glad that somebody finally stepped up to do it.
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]
It makes a difference.
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]
It might also provide some perspective to point out that back when OS X was the only desktop with a modern compositor it was primitive compared to today, there's been a decade of enhancement in the design since then. Application resize performance and memory usage for display buffers were both areas that had major performance improvements over the lifetime of that system. The addition of GPU acceleration was also a major improvement that was lacking in the initial implementation. Wayland gets to benefit from the decade of operational experience with the Mac OS X compositor and graphics stack.
|
|||||||||||||