Recent Features
| |||||||||||||
LCA: The ways of WaylandLCA: The ways of WaylandPosted Feb 14, 2013 15:30 UTC (Thu) by nix (subscriber, #2304)In reply to: LCA: The ways of Wayland by rqosa Parent article: LCA: The ways of Wayland
Yeah, quite. And the XRender case is crucial for getting scrolling of large text windows to work efficiently over the network (since you don't have to retransmit a giant buffer every time, just a bunch of glyph positions).
Apparently the only way this will work in Wayland is for every single toolkit to implement its own remoting protocol, probably all with regular compatibility breaks and all handling authentication differently and all with most of the same failures of the X protocol.
This is, apparently, progress. But we can remote the GIMP and stuff that mostly does graphical output of non-glyphs or never wants to scroll them really fast now!
(Log in to post comments)
LCA: The ways of Wayland Posted Feb 14, 2013 16:55 UTC (Thu) by raven667 (subscriber, #5198) [Link]
It seems that for the scrolling window case that there are several techniques which could be employed that would be faster than the degenerate case of repainting the whole buffer every frame such as detecting the motion and only sending changed portions or since "every frame is perfect" you could just throttle the number of frame updates sent by a fast changing window while still being completely responsive and without corrupting the output. This is the same kind of special case as redirecting compressed video streams straight through and decoding on the display side, implementing compression and acceleration techniques that are already known.
LCA: The ways of Wayland Posted Feb 14, 2013 17:57 UTC (Thu) by nix (subscriber, #2304) [Link]
Have you ever tried to do interactive scrolling on a window with throttled updates? I have (while debugging Emacs scrolling). It is intolerable, very like driving with a variable lag in the steering.
Scrolling text efficiently is not best solved as a problem in general video compression: we know a lot about the nature of a scrolling window and can come up with very much better examples. (Proof by example: core text X scrolling back in the day, or X scrolling with XRender objects now that glyph cache defragmentation is implemented. It moves so fast that all you can see is a blur. I would consider it a very serious regression if it only updated a few times a second! Perhaps this doesn't matter much for xterms but it certainly matters for text editors. And I spend my whole day in one of those.)
LCA: The ways of Wayland Posted Feb 14, 2013 18:33 UTC (Thu) by raven667 (subscriber, #5198) [Link]
What about capturing the PTY and redirecting it to a local terminal emulator? That should be the most performant, yes?
LCA: The ways of Wayland Posted Feb 15, 2013 17:56 UTC (Fri) by nix (subscriber, #2304) [Link]
Hm, yeah, that would work. Feels like a disgusting kludge to have to start all connections locally and ssh out though, which is basically what you're suggesting. And if I want to start something graphical while I'm on the remote system, I'm SOL, which is a strict loss of functionality over today.
LCA: The ways of Wayland Posted Feb 19, 2013 23:38 UTC (Tue) by raven667 (subscriber, #5198) [Link]
I was thinking about this and just did some very informal testing with the VNC implementation that comes with stock Mac OS X Screen Sharing and was able to remote a large terminal running "find /" to my laptop over wireless at home with very acceptable performance. There was at most 100ms of latency from hitting ctrl-c and having the output stop and the output was updating very quickly. Looking at my network stats it hit a peak of 2300 packets per second and 3MB/sec, the network latency between the devices is about 20ms. So what current implementation do seems to be OK at least as far as I'm concerned, at least with the latencies and bandwidth I have available at home 8-).
LCA: The ways of Wayland Posted Feb 14, 2013 18:00 UTC (Thu) by daniels (subscriber, #16193) [Link]
> probably all with regular compatibility breaks
Awesome, how fun is arguing against strawmen? Definitely one of my favourite pastimes.
You should have a play around with scrolling using the remote Weston prototype: it's actually shockingly performant, even over latency and throughput-limited networks (e.g. a conference in Australia to a host in the UK).
LCA: The ways of Wayland Posted Feb 14, 2013 19:35 UTC (Thu) by drag (subscriber, #31333) [Link]
> And the XRender case is crucial for getting scrolling of large text windows to work efficiently over the network (since you don't have to retransmit a giant buffer every time, just a bunch of glyph positions).
Is this why Gnome-terminal is much better at displaying text over a network then Xterm is?
LCA: The ways of Wayland Posted Feb 15, 2013 17:57 UTC (Fri) by nix (subscriber, #2304) [Link]
Well, they both use XRender. It is possible that the render extension is dropping back to a software fallback in the xterm case and not in the gnome-terminal case. perf (or other systemwide profiling tool) should tell you.
LCA: The ways of Wayland Posted Feb 15, 2013 8:13 UTC (Fri) by paulj (subscriber, #341) [Link]
This is a bit of a daft comment from you, an otherwise well-informed commentator here. You surely must be well aware that:
a) Linux has shared libraries
b) In X11 applications *ALSO* _each_ "implement" their own remoting facility
c) X11 applications do this by using toolkit libraries, which link to libraries implementing X11.
d) There are at least 2 different libraries which implement X11, that are widely used.
The Wayland remoting is highly unlikely to be much different. Applications will link to a plethora of toolkits which will link to a smaller number of remoting libraries, which may implement a potentially smaller number again of actual remoting protocols.
Just like how X11 is supported in applications today.
Bizarre answer Posted Feb 15, 2013 10:32 UTC (Fri) by renox (subscriber, #23785) [Link]
Hum, the way I see it is your reply which is daft, nix is pointing out a particular use case (remote text rendering) where XRender may significantly outperform Wayland, and that this may become an issue, what's so daft about it?
As for me, I'll wait and see: on the paper XRender is much better for remote text rendering (an important use case), but X's implementation is so old and full of warts, that I think measurements are needed before implementing workaround on top of Wayland.
LCA: The ways of Wayland Posted Feb 15, 2013 18:06 UTC (Fri) by nix (subscriber, #2304) [Link]
True. I never really thought of it like that, but libX11 is indeed a library implementation of the client side of the X protocol. I think the key is that it does nothing else (well, actually it does, too much else, that's why XCB is slowly taking off).
I guess what I'm really hoping is that something like XCB turns up to permit toolkits to do exactly what XCB/Xlib currently permit, i.e. remoting without exchanging vast heaps of compressed bitmaps. The downside is that now the toolkits -- or someone -- have to write the server side as well, and that requires coordination between toolkits, which historically they have been bloody awful at (mostly due to Gtk's flaming NIH syndrome, as I understand it).
I suppose you could use X-on-Wayland and XCB/Xlib for that, but in that case I'm afraid I don't really see much benefit to Wayland at all, other than I suppose a really disruptive way to get code cleanliness (and it's not like you can ditch the X server if you're still running X-on-Wayland for a lot of your work). Perhaps that's because a lot of the important X apps I run, I run remotely, excepting konsoles and the occasional game, which as DRI2 users are talking directly to the graphics card *already* without any need for Wayland...
|
|||||||||||||