This post seems to be slightly misinformed about Wayland. I can't say much about Mir as I'm not as familiar with it.
1. You can use OpenGL, OpenGL ES, Software, etc. to render windows in Wayland and most likely in Mir.
2. 2D acceleration depends on the widget toolkit and not Wayland. Wayland doesn't do 2D acceleration or need to do so since it is only responsible for compositing windows (which is as fast in 3D). If 2D acceleration is used to draw these windows, it isn't affected by the use of Wayland or X11 in any way. Wayland has a public mailing list that has much more reliable info than Phoronix and LWN.
3. This is probably the most interesting point raised. Providing xrandr functionality in wayland is much easier than in X11. This is because you have to support a lot of legacy features in X11 that you don't in Wayland.
4 (I added this one) Throughout the article, he seems to assume that no drivers will support Wayland. Wayland was buit to reuse most of the X11 drivers by being able to use DRI2. Mir seems to be able to take this one step further by being able to leverage existing Android drivers (there was a prototype of this in Wayland a while back).
I would like to finish by saying that I agree with the premise but not for the reasons given. The reason you won't see Wayland and Mir in a distro this year is because X11 is tried and tested. You don't replace something that critical to the user experience on a whim: you make sure it works and works for everyone first. Having said that, you will see Wayland and/or Mir faster than you'd expect.
1. Arch already has Wayland in its official repositories.
2. KDE already has preliminary support
3. Intel is driving Wayland development, so integrated cards will likely work without a hitch
4. Systemd was another large change with lots of FUD, and it's already default in high-profile distros (OpenSUSE, Fedora and soon RHEL 7). Even Canonical's on board.
This article is mostly FUD. I think we'll see a relatively stable KDE on Wayland this year. I doubt the Wayland team is that optimistic, but it's moving at an incredible pace.
I actually ran wayland on my laptop a few days ago. I'd be prepared to try switching full time once they let me configure my touchpad.
As for acceleration - you can actually run wayland on fbdev with a fully software compositor. I wouldn't be surprised to see something like E18 running as a sw compositor for wayland.
Speed, to a certain extent, doesn't matter. What matters is intelligent drawing. Double-buffering updates, not showing partially laid-out screens, etc. Software rendering is plenty fast for the relatively simple drawing that makes up a typical application's user interface, and EGL does support the most essential bit of hardware acceleration--bit blit (using the image as a texture).
In fact Qt was speed up noticeably for most use cases by their 'raster' graphics engine instead of the native X11 one.
Some of that is due to the X11 engine not being optimal, but then again if it's difficult to generate an optimal X11 rendering toolkit and it's easy to make a fast software renderer, then maybe that makes choices like these (moving to software-everything) seem more reasonable in retrospect.
Only to the extent that it's not fast enough, which it clearly is given that iOS doesn't hardware-accelerate CoreGraphics. Anything done wrong can be bad, but flicker is really really bad. Pretty much only Apple gets it right in that regard (maybe Jellybean, I haven't used it much).
I think the author mostly has a point with regards to backwards compatability; however, mobile app development is already centered around OpenGL ES graphics, so I don't see it as a major stumbling block for new code. Of the three points he made, the shift from XRandr to mode-setting sounds like the most potentially troublesome.
I think article is completely missing the point. For now MIR is going to use X server as backend. Priority for Canonical is to create single API portable between Android and Linux Desktop. Sure Android compositor will eventually replace X server, but it will be just side effect.
It is. Km looking forward to having to deal with people talking out their ass for months like they did and continue to do about SecureBoot. If you don't understand it, don't comment. Its kinda like how the anti-Wayland falsehoods from the MirSpec doc continue to be parroted. Started from ignorance and perpetuated by it.
Re OpenGL: If I understand this https://wiki.ubuntu.com/MirSpec correctly, libhybris is what is currently used to cobble together the use of SurfaceFlinger as a compositor for Ubuntu Touch. Ubuntu intends to pull this compatibility with Android's HAL, more specifically the GPU drivers, into mir, which will enable mir to be binary compatible with GPU drivers written for Android, which support OpenGL.
Mir has specific goals for hardware and binary driver compatibility and Canonical has demonstrated proof of concept by using SurfaceFlinger as a compositor for Ubuntu Touch.
AFAIK Android drivers support only OpenGL ES, not regular OpenGL; that's the problem he's talking about. As similar as they may be, apps written for one will not run on the other.
But this just points out an inherent trait in most software, if you are trying to replace something older, you better at least have feature parity, and some killer feature to drive adoption.
In Wayland, I can easily see the ability to run an X server on top as a motivator, but in the end the killer feature needs to be performance and a tide of new software targeting EGL / WaylandInput insteaf of GLX / XInput.
You don't need feature parity, because there are many features used only by a small handful of people.
When the first iPod came out, it didn't have feature parity. No wireless, no FM radio, smaller drive, no Windows compatibility. But it was better at the important tasks (finding music on your library, controlling playback). Similarly the first iPhone OS was missing quite a few features compared to BB/WinMo.
If Wayland or Mir can do a better job for the 80% or 90% case, they could easily displace X11. The fact that they are cleaner codebases (since they aren't 20+ years of layers) means they can probably respond to new use cases or important gaps faster than X11.
if you are trying to replace something older, you better at least have feature parity
Which is why there has been so much fuss. I haven't kept up, but has the Wayland project changed their tune on networkable graphics? I will grant that X could use some uncrustifying, but I think the general gist of the OP is correct: there is just so much that X offers that Wayland and Mir will have to catch up to (assuming they can, which requires not just time and effort, but forward thinking on design and architecture).
And as for performance, my N900, a four years old phone, runs X just fine. The sad experience I have had with software (including OSS), is that the newly born projects are almost always designed without paying attention to efficiency, usually through a lack of awareness because people are so used to fast hardware these days.
That's weird, Weston runs fine on my desktop with nouveau and Intel on my Macbook Air. Oh, and non-Xlib GTK apps too. And apparently Chrome too though I haven't had a chance to confirm this yet.
This post seems to be slightly misinformed about Wayland. I can't say much about Mir as I'm not as familiar with it.
1. You can use OpenGL, OpenGL ES, Software, etc. to render windows in Wayland and most likely in Mir.
2. 2D acceleration depends on the widget toolkit and not Wayland. Wayland doesn't do 2D acceleration or need to do so since it is only responsible for compositing windows (which is as fast in 3D). If 2D acceleration is used to draw these windows, it isn't affected by the use of Wayland or X11 in any way. Wayland has a public mailing list that has much more reliable info than Phoronix and LWN.
3. This is probably the most interesting point raised. Providing xrandr functionality in wayland is much easier than in X11. This is because you have to support a lot of legacy features in X11 that you don't in Wayland.
4 (I added this one) Throughout the article, he seems to assume that no drivers will support Wayland. Wayland was buit to reuse most of the X11 drivers by being able to use DRI2. Mir seems to be able to take this one step further by being able to leverage existing Android drivers (there was a prototype of this in Wayland a while back).
I would like to finish by saying that I agree with the premise but not for the reasons given. The reason you won't see Wayland and Mir in a distro this year is because X11 is tried and tested. You don't replace something that critical to the user experience on a whim: you make sure it works and works for everyone first. Having said that, you will see Wayland and/or Mir faster than you'd expect.
I completely agree. Some interesting factoids:
1. Arch already has Wayland in its official repositories.
2. KDE already has preliminary support
3. Intel is driving Wayland development, so integrated cards will likely work without a hitch
4. Systemd was another large change with lots of FUD, and it's already default in high-profile distros (OpenSUSE, Fedora and soon RHEL 7). Even Canonical's on board.
This article is mostly FUD. I think we'll see a relatively stable KDE on Wayland this year. I doubt the Wayland team is that optimistic, but it's moving at an incredible pace.
I actually ran wayland on my laptop a few days ago. I'd be prepared to try switching full time once they let me configure my touchpad.
As for acceleration - you can actually run wayland on fbdev with a fully software compositor. I wouldn't be surprised to see something like E18 running as a sw compositor for wayland.
Speed, to a certain extent, doesn't matter. What matters is intelligent drawing. Double-buffering updates, not showing partially laid-out screens, etc. Software rendering is plenty fast for the relatively simple drawing that makes up a typical application's user interface, and EGL does support the most essential bit of hardware acceleration--bit blit (using the image as a texture).
In fact Qt was speed up noticeably for most use cases by their 'raster' graphics engine instead of the native X11 one.
Some of that is due to the X11 engine not being optimal, but then again if it's difficult to generate an optimal X11 rendering toolkit and it's easy to make a fast software renderer, then maybe that makes choices like these (moving to software-everything) seem more reasonable in retrospect.
For touch interfaces the lag between input and render is critical, and double-buffering if done wrong can kill you.
Software rendering an opaque rect may be fine, but add in some big semi-transparent overlays and performance drops.
Only to the extent that it's not fast enough, which it clearly is given that iOS doesn't hardware-accelerate CoreGraphics. Anything done wrong can be bad, but flicker is really really bad. Pretty much only Apple gets it right in that regard (maybe Jellybean, I haven't used it much).
1 reply →
Point 1 is incorrect: You can use the full-desktop (non-ES) openGL with egl with no problems - just pass 'EGL_OPENGL_API' to eglBindAPI.
I don't know how good the support for this is from different drivers, however.
There is also Regal, a library that implements GL on top of GLES2. So it should still be possible even with only GLES2.
AFAIK, OS X has been running fine (not super-fast, but acceptable) without 2D acceleration for 13 years.
Also, doesn't Compiz still have some tearing or artifacting during window resize? Wayland is supposed to eliminate that.
I'm confused, I thought 2D acceleration was introduced with 10.4. I'm not a Mac user, so I'm not sure, but Wikipedia (http://en.wikipedia.org/wiki/Quartz_%28graphics_layer%29) seems to agree.
"Quartz 2D Extreme ... still remains disabled by default" Somebody correct me if this is wrong.
7 replies →
The author of the blog post just told me it's DRI3[1] that eliminates it, not Wayland itself.
[1]: http://www.phoronix.com/scan.php?page=news_item&px=MTMwN...
I think the author mostly has a point with regards to backwards compatability; however, mobile app development is already centered around OpenGL ES graphics, so I don't see it as a major stumbling block for new code. Of the three points he made, the shift from XRandr to mode-setting sounds like the most potentially troublesome.
There was a presentation on the mode-setting architecture at FOSDEM in February, I'm going to look at it now: http://www.phoronix.com/scan.php?page=news_item&px=MTI5N...
I think article is completely missing the point. For now MIR is going to use X server as backend. Priority for Canonical is to create single API portable between Android and Linux Desktop. Sure Android compositor will eventually replace X server, but it will be just side effect.
I think everything you said is incorrect.
https://wiki.ubuntu.com/MirSpec
It is. Km looking forward to having to deal with people talking out their ass for months like they did and continue to do about SecureBoot. If you don't understand it, don't comment. Its kinda like how the anti-Wayland falsehoods from the MirSpec doc continue to be parroted. Started from ignorance and perpetuated by it.
Re OpenGL: If I understand this https://wiki.ubuntu.com/MirSpec correctly, libhybris is what is currently used to cobble together the use of SurfaceFlinger as a compositor for Ubuntu Touch. Ubuntu intends to pull this compatibility with Android's HAL, more specifically the GPU drivers, into mir, which will enable mir to be binary compatible with GPU drivers written for Android, which support OpenGL.
Mir has specific goals for hardware and binary driver compatibility and Canonical has demonstrated proof of concept by using SurfaceFlinger as a compositor for Ubuntu Touch.
AFAIK Android drivers support only OpenGL ES, not regular OpenGL; that's the problem he's talking about. As similar as they may be, apps written for one will not run on the other.
Screen rotation is probably essential, but is screen resizing? I'm not sure it is. I think we're all just used to it.
Some use-cases for screen resizing off the top of my head:
- plug external screen with different resolution on your mobile device (laptop or smartphone with miniHDMI) and switch to that
- full-screen app want to change to different resolution for performance reasons
Plugging a projector or TV as well.
But this just points out an inherent trait in most software, if you are trying to replace something older, you better at least have feature parity, and some killer feature to drive adoption.
In Wayland, I can easily see the ability to run an X server on top as a motivator, but in the end the killer feature needs to be performance and a tide of new software targeting EGL / WaylandInput insteaf of GLX / XInput.
You don't need feature parity, because there are many features used only by a small handful of people.
When the first iPod came out, it didn't have feature parity. No wireless, no FM radio, smaller drive, no Windows compatibility. But it was better at the important tasks (finding music on your library, controlling playback). Similarly the first iPhone OS was missing quite a few features compared to BB/WinMo.
If Wayland or Mir can do a better job for the 80% or 90% case, they could easily displace X11. The fact that they are cleaner codebases (since they aren't 20+ years of layers) means they can probably respond to new use cases or important gaps faster than X11.
if you are trying to replace something older, you better at least have feature parity
Which is why there has been so much fuss. I haven't kept up, but has the Wayland project changed their tune on networkable graphics? I will grant that X could use some uncrustifying, but I think the general gist of the OP is correct: there is just so much that X offers that Wayland and Mir will have to catch up to (assuming they can, which requires not just time and effort, but forward thinking on design and architecture).
And as for performance, my N900, a four years old phone, runs X just fine. The sad experience I have had with software (including OSS), is that the newly born projects are almost always designed without paying attention to efficiency, usually through a lack of awareness because people are so used to fast hardware these days.
5 replies →
That's weird, Weston runs fine on my desktop with nouveau and Intel on my Macbook Air. Oh, and non-Xlib GTK apps too. And apparently Chrome too though I haven't had a chance to confirm this yet.
The article is utter bullshit.
EGL can work with OpenGL non-ES just fine (as long as the driver supports that, which Mesa of course does).
2D acceleration can be layered on top of OpenGL reasonably fine, with things like cairo-gl, Firefox backends, Qt/OpenGL, etc.
I'm not totally sure about rotation/resizing, but I'd guess it's supported and anyway it's not essential on desktop.
The author is an idiot.