[go: up one dir, main page]

|
|
Log in / Subscribe / Register

Wayland - Beyond X (The H)

Wayland - Beyond X (The H)

Posted Feb 16, 2012 13:08 UTC (Thu) by renox (guest, #23785)
In reply to: Wayland - Beyond X (The H) by farnz
Parent article: Wayland - Beyond X (The H)

> XRender is better than core X11, but is still neither good enough for modern toolkits (which are moving to OpenGL to escape the problems with XRender)
Which issue are you talking about? The speed of the rendering?
I expect that any protocol which is network efficient (WAN) will reduce the rendering speed, it's a tradeoff..

> nor as efficient as something like NeWS was.
Sure, but I don't think that it's possible to keep current toolkits and have them implement something like NeWS or Fresco/Berlin.

But current toolkits already support X11 so if there was a Wayland2.0 which was (Wayland1.0 + the useful parts of X11 to have network (WAN) access), then it should be possible to have the toolkits use this..


to post comments

Wayland - Beyond X (The H)

Posted Feb 16, 2012 13:41 UTC (Thu) by farnz (subscriber, #17727) [Link] (2 responses)

XRender is rather limited in functionality, as compared to OpenGL (only considering the 2D rendering case here). As a result, you end up rendering parts of the toolkit as bitmaps (which you ship over the wire as-is when running networks), when a better API like OpenGL lets you offload work to hardware. Toolkit authors want to produce prettier toolkits than XRender can support (see Clutter for an example of a toolkit that makes use of OpenGL features that just can't be efficiently rendered via XRender).

If they're happy with X11's protocol, they're unlikely to go to the effort of porting to Wayland - why bother coding a completely new backend, when your existing X11 backend will already work with Wayland? Equally, why limit yourself to systems running Wayland if you can work with any systems that run X11?

Note that Wayland is still a success if all it does is act as the construction kit for X11 systems that integrate window management, input handling, and compositing. It doesn't need all the clients to talk native Wayland to have succeeded.

Wayland - Beyond X (The H)

Posted Feb 16, 2012 17:18 UTC (Thu) by renox (guest, #23785) [Link] (1 responses)

> XRender is rather limited in functionality, as compared to OpenGL
Yes but:
1) OpenGL is a moving target
2) You cannot simply send OpenGL commands from the client to the server otherwise any command to allocate something would create a round trip.
So you'd have to have a smart proxy on the client, goto (1).
3) With some luck, OpenGL commands to read pixels from buffers would not be an issue as they're already slow, so they're unlikely to be used.

> If they're happy with X11's protocol, they're unlikely to go to the effort of porting to Wayland

I don't understand your remark: there is work to port GTK and Qt to Wayland, clearly some developers want the faster local rendering that Wayland should provide..

The question is about the remote rendering backend: should the X11 backend be kept forever? Can it be improved for WAN access(*)?
Or is-it possible to replace it with something even better for WAN on top of Wayland?

*:After all, in the long run (if Wayland is ported to other Unix), this should be its main purpose.

Wayland - Beyond X (The H)

Posted Feb 16, 2012 18:42 UTC (Thu) by farnz (subscriber, #17727) [Link]

While OpenGL is a moving target, it is a standard, and what's on offer is extended, not reduced. You can choose a useful subset, available on all interesting platforms, and just use that, while still getting more than XRender offers you. Given that people are moving toolkits to OpenGL, there's clearly a demand for more than XRender offers from the perspective of toolkit authors.

Explaining my remark in more depth; nothing in the Wayland world stops people sticking to X11 indefinitely. If Wayland + XRender (or Wayland + OpenGL 1.4 - the upper limit of indirect GLX) is Good Enough, toolkit authors are unlikely to expend the effort to port to Wayland for no net gain. Given that the only gain from Wayland is to permit you to drop legacy code related to the network-transparent subset of X11, the only sensible reason for toolkits to port over and stop caring about X11 is that they want to do things that they can't do network-transparently in X, either.

Therefore, should toolkits stop bothering to maintain a network-transparent X11 backend, it will be because they're doing things that they couldn't do in network-transparent X11. The benefit of Wayland here is that they have to explicitly decide that "not network transparent" is acceptable - they can't simply be an X11 application that does not work over the network due to DRI2 dependencies.

Thus, the toolkits have to make a decision about remote rendering; is it an irrelevance to their users? Is X11 good enough (in which case they will maintain an X11 backend)? Is there a better way (in which case they will implement it, and possibly kill off Wayland in the process)?


Copyright © 2026, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds