There's some irony here...

Posted Feb 14, 2012 1:09 UTC (Tue) by dlang (guest, #313)
In reply to: There's some irony here... by Kit
Parent article: Wayland - Beyond X (The H)

something as simple as moving a window around will produce a huge delta.

Also, you can only use the GPU on a box if you limit yourself to one display per box, if you have several remote displays going on, sharing the GPU becomes a limiting factor.

being able to leverage remote GPUs for the display would be a very good thing, but unless you design it in to the protocol early, you are very unlikely to be able to retrofit it and have it work sanely.

to post comments

There's some irony here...

Posted Feb 14, 2012 1:55 UTC (Tue) by Kit (guest, #55925) [Link] (13 responses)

> something as simple as moving a window around will produce a huge delta.

Only if you're following the VNC "whole-desktop" model, and would likely require extra work.

The logical way (at least IMO), would be to treat all the applications as distinct objects, with their own damage events. The computer you're sitting at would take all the windows its getting from the remote system, and then composite them on to the screen. Just like how XComposite made it so applications wouldn't have to redraw themselves whenever a window was moved above it, this would enable the compositor running across the internet from you to not care if you were moving the windows around the screen like a madman.

Then there would be no delta from moving a window around (well, unless you're talking about a sub-window in an MDI application...).

> being able to leverage remote GPUs for the display would be a very
> good thing, but unless you design it in to the protocol early, you
> are very unlikely to be able to retrofit it and have it work sanely.

Since applications render into an off-screen buffer, that is then passed to the Compositor (Weston, in the case of the current one), which then paints it to the screen. At least at a high level, this should be quite conducive to using remote GPUs (well, assuming 'remote' is the system the application is running on, not the system you're sitting at- beyond whatever the local compositor decides to do when it's doing the final screen painting).

There's some irony here...

Posted Feb 14, 2012 2:44 UTC (Tue) by dlang (guest, #313) [Link] (5 responses)

>> something as simple as moving a window around will produce a huge delta.

> Only if you're following the VNC "whole-desktop" model, and would likely require extra work.

remember that the Wayland people are the ones saying that the solution to network transparency is VNC.

There's some irony here...

Posted Feb 14, 2012 5:49 UTC (Tue) by Per_Bothner (subscriber, #7375) [Link] (4 responses)

remember that the Wayland people are the ones saying that the solution to network transparency is VNC.

No, they're saying a solution is something like VNC. Using VNC is useful because it supports multi-platform remoting, but a protocol tuned for Wayland would obviously be more efficient for Wayland-to-Wayland remoting. But designing and implementing the protocol is not a priority until the local case is stable - as long as they keep the issue in mind, which they seem to be doing.

There's some irony here...

Posted Feb 14, 2012 6:02 UTC (Tue) by raven667 (subscriber, #5198) [Link] (3 responses)

Apparently it is more fun to make strong statements based on selective misreading rather than have an actual discussion. Argument by vehemency. Personally i am surprised no one has mentioned SPICE as a possible candidate for Weyland remoting although maybe the NX folks will come out with something neat. VNC is pretty much guaranteed to be supported in any case. Also it's not like X11 will magically disappear overnight, all the current toolkits will probably continue to work for the foreseeable future and there is no problem running X11 on Weyland, much like how X11 runs on other systems

There's some irony here...

Posted Feb 14, 2012 6:30 UTC (Tue) by dlang (guest, #313) [Link] (2 responses)

the concern is not about the difficulty in running X11 apps on a Wayland server. That works today (plus if it didn't work, Wayland would be pretty hard to bootstrap)

the concern is getting future killer app Y that was built with a Wayland graphics library to run on a system that uses X11 for it's display. This will probably start to be a problem a few months after Fedora and/or Ubuntu ship with Wayland as the default display instead of X11 (not that the killer app will need anything that Wayland provides, it's just that it will be build using the new 'cool and trendy' graphics library.

or alternatively, make it so that you can use Wayland in the places where people currently use X11 network transparency.

There are a lot of people writing infrastructure code for Linux that don't seem to have any Unix experience. This doesn't have to be a bad thing, but when these people dismiss existing functionality as "nobody could ever want that", it then becomes a problem. Especially if this work goes in to a major distro.

There's some irony here...

Posted Feb 14, 2012 7:03 UTC (Tue) by raven667 (subscriber, #5198) [Link]

I dunno, I would still expect apps to use toolkits such as QT or GTK+ which can output to several different kinds of graphics drivers, including X11. I suppose if someone did write a "killer app" which didn't use a toolkit and was directly speaking the Weyland protocol and you didn't want to run it over VNC and a high performance remote display protocol hadn't yet been implemented then that could be a problem. That's a fair number of "ifs" though.

There's some irony here...

Posted Feb 14, 2012 9:20 UTC (Tue) by daniels (subscriber, #16193) [Link]

There are a lot of people writing infrastructure code for Linux that don't seem to have any Unix experience.

As far as I can tell these days, True UNIX Experience is limited to those who exclusively comment on LWN, Reddit and Hacker News, rather than those who write code.

There's some irony here...

Posted Feb 14, 2012 8:56 UTC (Tue) by marm (guest, #53705) [Link] (6 responses)

> Only if you're following the VNC "whole-desktop" model, and would likely require extra work.

Well, and what about scrolling the contents inside a window?

There's some irony here...

Posted Feb 14, 2012 9:47 UTC (Tue) by alankila (guest, #47141) [Link] (5 responses)

This keeps on being brought up.

While I don't know if it will ever get done, nothing at all would prevent an application from supplying the display system a rendering hint that says: "in my window texture, at rectangular region (x1, y1) to (x2, y2), the contents are shifted up by z pixels". It would do this at the same time when it pushes an updated texture for the compositor.

Now suppose remoting is done through a dumb transmit-pixel-images kind of protocol. A hint like this would allow the compositor to send this event to the remote display followed by the z rows of data which appeared at either top or bottom, thus achieving what must be the optimum efficiency.

These events could be generated by the relevant toolkits when they can prove that the proposed optimization is valid. Things like fixed backgrounds in scrollable areas would break this kind of optimization, although ways would exist to get around even that (instead of working with the single fully rendered window texture, work with the individual textures that comprise the UI elements, so a textarea is one texture at specific coordinates laid over a background texture, etc.).

There's some irony here...

Posted Feb 14, 2012 10:30 UTC (Tue) by marm (guest, #53705) [Link]

That's a neat idea. If it will ever get done, as you say... I agree that X11 has grown to an unsustainable state, but I still have a sad feeling that Wayland is motivated much more by eye candy than by usability. But let us see.

There's some irony here...

Posted Feb 14, 2012 21:56 UTC (Tue) by HelloWorld (guest, #56129) [Link] (3 responses)

> While I don't know if it will ever get done, nothing at all would prevent an application from supplying the display system a rendering hint that says: "in my window texture, at rectangular region (x1, y1) to (x2, y2), the contents are shifted up by z pixels". It would do this at the same time when it pushes an updated texture for the compositor.
This is precisely the sort of stuff that doesn't belong in Wayland. If you add things like this, it is all too tempting to add things like an optimization for lines being drawn and one for characters being drawn and oops, you just invented a new rendering protocol.
That isn't necessarily a bad idea, but it should be done separately.

There's some irony here...

Posted Feb 15, 2012 19:15 UTC (Wed) by alankila (guest, #47141) [Link] (2 responses)

Well, whatever way the remoting gets done. Not saying it has to be in Wayland's protocol, just saying that reasonably efficient scrolling is possible given that somebody who knows how the display changed will tell the information, rather than loses it and then requires some expensive rediscovery process to happen...

There's some irony here...

Posted Feb 15, 2012 19:20 UTC (Wed) by HelloWorld (guest, #56129) [Link] (1 responses)

Well, this is exactly what Høgsberg is saying: network transparency should be implemented in the toolkit, because the toolkit has access to the relevant information.

There's some irony here...

Posted Feb 15, 2012 19:24 UTC (Wed) by dlang (guest, #313) [Link]

but if it's only implemented in each toolkit, then you will end up with a nightmare of different remoteing protocols, and the resulting compatibility issues that this raises.

and what happens if one of these toolkits doesn't support the display mode on your platform (since each toolkit will need to write a sender and receiver for it's protocol)