Wayland preview

Yes, I saw that too.  One thing I like about RasPi is that it currently draws my X Windows graphics properly, as opposed to my Ubuntu 11.10 machine which sometimes has delayed rendering problems with diagonal lines and arcs.  They sometimes don't show up until I click the window's title bar, and I have no idea where in the Emperor's Old Clothes the problem might be.

So when I read that an adaptation layer (XWayland) will be provided, I have misgivings.  When I read that Wayland flings images around instead of graphical objects, my misgivings intensify.  At this point, I'm wondering if the gift horse is really a white elephant?

[Edit: changed "Emperor's New Clothes" to "Emperor's Old Clothes".  Sorry about that, C.A.R.]

Yes, it sounds like existing X applications will need to use an adaptation layer,

which will make them slower than they already are, but applications that use

GTK or Qt instead of X can run without an adaptation layer, with the potential

of a speedup.

coder27 wrote:

 

Yes, it sounds like existing X applications will need to use an adaptation layer,

which will make them slower than they already are, but applications that use

GTK or Qt instead of X can run without an adaptation layer, with the potential

of a speedup.

OK, so what do they use for drawing graphics and text and clipboard, so I can bypass them as well?  I have my own adaptation layer, so it's easy for me to switch from Xlib and Xft calls to something else.  I've just haven't come across something that's given me a good enough reason to switch.  I've found Xlib and Xft on every GNU/Linux system I've ported to.

from the faq:

What is the drawing API?

"Whatever you want it to be, honey". Wayland doesn't render on behalf of the clients, it expects the clients to use whatever means they prefer to render into a shareable buffer. When the client is done, it informs the Wayland server of the new contents. The current test clients use either cairo software rendering, cairo on OpenGL or hardware accelerated OpenGL directly. As long as you have a userspace driver library that will let you render into a sharable buffer, you're good to go.

http://wayland.freedesktop.org/faq.html#heading_toc_j_3

"Will this be backwards-compatible with the 256MB Raspberry Pi Model B?"  -- Corbin Davenport

"Yes. All the work’s being done by the GPU."  -- Liz

"We’re still working to improve performance and memory consumption"  -- Eben

gpu_mem=128

    How much memory to reserve for the VideoCore, i.e. framebuffers, GL textures,

http://wayland.freedesktop.org/raspberrypi.html

Funnily enough, if Pi becomes an early adopter of Wayland, it'll be a feather in its cap, because X11 has needed a major kick in the pants and some fundamental design changes for well over a decade now.  Some would say two.

The many Wayland articles list a whole slew of reasons why X11 isn't adequate, but I've always considered a different one to be most important.  Single Points of Failure are bad engineering, period.  The fact that all the X11 applications connected to a given X11 server will die when the server drops is simply ridiculous.  It's not a primary goal of Wayland to remove SPoFs, but the project offers an excellent opportunity for it.

Of course, with change comes pain.  You need Xlib and Xft on every system to ensure your app can be ported, and yes, that is an important issue.  On the positive side though, the Wayland people seem to be considering backwards compatibility with traditional X11 quite seriously.

I like change (it's part of progress), and I think that this one is for the better.  Network transparency will come from a different angle, a remoting protocol, which I think is the right place for it.

Morgaine.

Wayland is stuck with a nasty chicken vs egg problem. As it's such a different beast it effectively breaks all the existing X11 apps, no users means no focus on developing it further etc.

So they either spend lots of effort developing an X11 translation layer, or spend the effort on both QT & gtk+2 toolkits, and if either of those translations turns out to be under performant they could end up in trouble quickly.

I can't see it solving your SPOF problem either.  It's, rightly IMHO, targetting the now usual scenario where the single user is tightly coupled to the single screen on his device. Far less of a client / server setup than X11 has. So when my device dies will I be particularly bothered that the app is still running ?  Doubtful, and recent generations have been well trained that a reboot cures everything, good or bad engineering has little to do with it.

The bits I've read suggests they're going to use a version of the windows rdp protocol for their idea of network transparency. That's got upsides and downsides. It could mean that microsofts client will be able to connect to it and give lots of people a 'free' and well understood client experience. OTOH, I find the windows rdp stuff not so great, better than vnc certainly but still has it's issues - not that X11 doesn't as well.

If you've ever used the NoMachine nxclient stuff you probably already know that it does a mighty fine job of overcoming X11's deficiencies, but it also has an interesting additional mode where you connect remotely to your NX server and it then uses rdp to connect to a windows machine. Oddly, this conversion of rdp to compressed X11 usually results in a better user experience over any type of slow-ish or high latency network than raw rdp.

So change can be good, but needs doing right. Lots of change with either no visible user benefit, or worse with a performance hit from a translation layer, is unlikely to be seen as 'progress' by those pesky users who have a habit of voting with their feet

Still too early to tell for Wayland, but I think it's brave going for a very minimal desktop environment as currently implemented.

coder27 wrote:

 

but applications that use GTK or Qt instead of X can run without an adaptation layer, with the potential of a speedup.

As both Qt and GTK are just toolkits that run on top of X11 today, you still need to port them to run on top of Wayland. That may be an easier option though and could mean that a lot of apps need little modification. Qt and GTK would also likely bring both Gnome and KDE along for the ride as well as most of the major apps.

As both also have already been ported to Windows amongst other things, porting to wayland is potentially less of an issue than for anything that's tightly coupled to X11. The devil is in the details as always..

The big question, which I haven't seen answered, is whether there is much hope

that Wayland will somehow improve rendering speed within a window.  It appears

aimed mostly at improving the speed of dragging windows around on the desktop.

We have been told for a long time that browser speed is slow because X11 isn't

accelerated, but not to worry, when the GPU integration is done, browsers will

run at full speed.  And browser speed is currently slow even when there is only

one window open and you aren't dragging the window around at all.  So is there

a plan to fix that? 

If Qt and/or GTK are modified to target Wayland directly instead of running on top

of X11, will that make midori run faster in a single window?  Will some other browser

run faster by using Wayland?

Morgaine mentions single points of failure, but I think that's the least of RPF's worries

right now.  The were originally scheduled to have an educational release in 2011, then

it slipped to 2012, and now we are in 2013 with the 2013-2014 school year starting in

about 3 months, and they are announcing now that X11 applications are too slow,

including Scratch, Python's IDE, and web browsers.  So they are going to eliminate X11

from the desktop and have everything put back together for an educational release when? 

And with what single-window benefit?  And with what increase in memory overhead?

coder27 wrote:

 

If Qt and/or GTK are modified to target Wayland directly instead of running on top

of X11, will that make midori run faster in a single window?  Will some other browser

run faster by using Wayland?

 

...

 

What is the drawing API?

 

"Whatever you want it to be, honey". Wayland doesn't render on behalf of the clients, it expects the clients to use whatever means they prefer to render into a shareable buffer.

From your earlier comment, it sounds like Wayland doesn't have any sort of drawing functions -- Wayland just manages overlapping pixel arrays and couldn't care less what's in them.  So Qt, GTK, and Xlib would need to target something other than Wayland, such sending OpenGL messages directly to the GPU.  I seem to recall that RasPi open-sourced the user-space calls needed to send OpenGL messages, and that Eben promised that the low-level interface would be documented at some point.

So it sounds like a way to get high performance from a graphics application is for it to open an internal pixel buffer, send OpenGL messages to the GPU to draw to that buffer, and let Wayland overlap the window on the screen.  That's something worth looking forward to.  Meanwhile, I need to figure out how to do text in OpenGL.  It seem great for drawing triangles, but the last time I looked I couldn't find anything in OpenGL about text.  I assume it treats text as outline graphics, kind of like PDF, but I believe PDF converts renders specific fonts as pixel maps at some point so that it's not continuously calculating diagonal lines and Bézier curves.

X11 has a lot more than graphics rendering.  There's also GUI input, window manipulation, and clipboard functions.  If I go to OpenGL and Wayland, I'll have to find out who will do these for me.  Fortunately, I suspect I'll have plenty of time to find out and meanwhile X11 works quite nicely for me on RasPi (and "pretty well" on Ubuntu 11.10).