Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 23, 2013
An "enum" for Python 3
An unexpected perf feature
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
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)
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.
Posted Apr 12, 2012 11:30 UTC (Thu) by renox (subscriber, #23785)
Posted Apr 16, 2012 19:55 UTC (Mon) by rvfh (subscriber, #31018)
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.
Posted Apr 16, 2012 20:04 UTC (Mon) by dlang (✭ supporter ✭, #313)
Posted Apr 16, 2012 20:33 UTC (Mon) by renox (subscriber, #23785)
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).
Posted Apr 16, 2012 20:51 UTC (Mon) by Cyberax (✭ supporter ✭, #52523)
Posted Apr 17, 2012 17:15 UTC (Tue) by rvfh (subscriber, #31018)
> 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.)
Posted Apr 17, 2012 19:56 UTC (Tue) by renox (subscriber, #23785)
Posted Apr 17, 2012 20:28 UTC (Tue) by Cyberax (✭ supporter ✭, #52523)
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.
Posted Apr 27, 2012 7:16 UTC (Fri) by Duncan (guest, #6647)
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!
Posted Apr 12, 2012 10:14 UTC (Thu) by Cyberax (✭ supporter ✭, #52523)
Existing X applications won't be affected. X is going to be supported for the foreseeable future.
Posted Apr 12, 2012 12:53 UTC (Thu) by sorpigal (subscriber, #36106)
Posted Apr 12, 2012 14:43 UTC (Thu) by raven667 (subscriber, #5198)
Posted Apr 12, 2012 15:14 UTC (Thu) by tack (subscriber, #12542)
Posted Apr 13, 2012 5:13 UTC (Fri) by renox (subscriber, #23785)
Why are there glitches in the case you describe?
If this is driver related, Wayland won't help..
Posted Apr 12, 2012 15:15 UTC (Thu) by HelloWorld (guest, #56129)
Posted Apr 12, 2012 21:10 UTC (Thu) by sorpigal (subscriber, #36106)
Posted Apr 13, 2012 17:02 UTC (Fri) by drag (subscriber, #31333)
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.
Posted Apr 13, 2012 17:24 UTC (Fri) by raven667 (subscriber, #5198)
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds