The way to Wayland: Preparing for life After X [LWN.net]

The way to Wayland: Preparing for life After X

Posted Nov 20, 2010 19:49 UTC (Sat) by quotemstr (subscriber, #45331)
In reply to: The way to Wayland: Preparing for life After X by glisse
Parent article: The way to Wayland: Preparing for life After X

Not tearing doesn't require ditching X. All you have to do is have the compositor synchronize with the display: you can do that with triple bufering, or by putting the compositor in the X server.

What part of that requires ditching the X protocol and architecture?

(Log in to post comments)

The way to Wayland: Preparing for life After X

Posted Nov 20, 2010 20:29 UTC (Sat) by glisse (subscriber, #44837) [Link]

Tearing can be solve not too badly with compositor but without compositor please feel free to show me how to do it (it means thinks 10 times before even remotely believe you have one solution).

So now with a compositor here is what happens :
app->toolkit->render window(gtk/qt/cairo ...)->upload to X as a pixmap (memcpy new buffer allocation + others overhead)->compositor use it has a texture->screen

Wayland:
app->toolkit->render window(gtk/qt/cairo...)->give buffer id(ie send an int)->compositor use it as texture->screen

Suddenly you removed all the X protocol, all the memcpy non sense, all the painfull path to try to make it right in the DDX. And now life is beautifull. I am not even mentioning app half rendered and others rendering non sense of X.

X is painfull to accelerate and even more to get it right, i have been writing X driver for few years now and what i can tell you is that i prefer writing a GL driver than an X driver.

But please if you feel X is the right way come join us and wrote driver to truely use GPU with X.

Bottom line is if all X people says that they want wayland then it just means it's what you will get in your distribution sooner or later unless new people step up and shows all the X people how X was supposed to be done.

The way to Wayland: Preparing for life After X

Posted Nov 20, 2010 20:45 UTC (Sat) by quotemstr (subscriber, #45331) [Link]

Tearing can be solve not too badly with compositor

So you concede that tearing can be fixed within the X protocol.

please feel free to show me how to do it

You can do it with a novel technique called double buffering. I mean, it was only invented in the 1980s: you may not have heard of it yet.

app->toolkit->render window(gtk/qt/cairo ...)->upload to X as a pixmap (memcpy new buffer allocation + others overhead)->compositor use it has a texture->screen

Cairo and other toolkits can render directly using XRENDER or OpenGL. The XRENDER and OpenGL operations are sent symbolically to the X server, which then hands them off directly to the GPU. There's no client-side pixmap and memcpy involved. You're either disingenuous or ignorant.

X is painfull to accelerate and even more to get it righ

Boo hoo, programming is hard! Let's burn the place down instead.

wrote driver to truely use GPU with X

What specific operations that are not accelerated today would be accelerated under your proposed architecture?

i prefer writing a GL driver than an X driver

Your statement is nonsense. What's the difference? When writing an X driver, you don't have to care about it being for X per se. A graphics driver deals with the same primitives in any environment: mode setting and acceleration. That's why nVidia can use the same codebase for its drivers on all platforms.

if all X people says that they want wayland

If that's the case, then the X people have lost their minds.

The way to Wayland: Preparing for life After X

Posted Nov 20, 2010 23:55 UTC (Sat) by glisse (subscriber, #44837) [Link]

Double buffering, i surely never heard of it ... Likely because i am an ignorant :) But i don't want to be more disingenuous with you, was fun talking with you, can't wait seeing you on Xorg devel you have a lot of things to teach us.

The way to Wayland: Preparing for life After X

Posted Nov 22, 2010 0:32 UTC (Mon) by bronson (subscriber, #4806) [Link]

quotemstr, you sound like you're saying "It's just a software problem! That's easy!!"

Have you contributed any code to X? If you actually do have real-world experience with this codebase, then I am definitely interested in what you have to say. But if your point is that someone else can fix everything, I can only conclude that your shrill opinion carries very little water at all.