| |||||||||||||
Wayland and Weston 1.0 releasedWayland and Weston 1.0 releasedPosted Oct 24, 2012 16:18 UTC (Wed) by nix (subscriber, #2304)In reply to: Wayland and Weston 1.0 released by daniels Parent article: Wayland and Weston 1.0 released
The comment thread in <https://lwn.net/Articles/481138/> has several instances of Wayland boosters doing down network-transparency as useless.
I pointed out in that thread that sending giant bitmaps would be devastating for a major use case: scrolling windows full of lots and lots of client-side-rendered text. X has those glyphs in GlyphSets, so doesn't need to send all the giant images over again: things like VNC or SPICE do not, so a single one-line scroll of a full-screen xterm can take half a second or so under such remoting technologies, while under remote X it is nearly instantaneous (you can easily scroll the whole screen line-by-line under remote X in the time it takes VNC et al to scroll a single line).
I asked what Wayland has that provides the same speed boost over giant image lump transfer.
Answer came there none.
Apparently terminal emulators and text editors are not an important use case anymore. (A killer for me, since my Emacs, with huge windows full of lots of text, is *always* run network-remote. It's as fast remotely under X as it would be locally. Obviously it is intolerably slow over a slow remote link, but I'm not using it that way. Oh, and while Emacs supports Gtk and thus would be able to pick up any Gtk-side Wayland remoting support, I note that horrible problems in Gtk's existing support for remote X -- including coredumping whenever a display goes away -- have gone unfixed since 2002, so I am not confident that Gtk Wayland remoting would be in any better shape any time soon.)
(Log in to post comments)
Wayland and Weston 1.0 released Posted Oct 24, 2012 16:31 UTC (Wed) by wmf (guest, #33791) [Link] sending giant bitmaps would be devastating for a major use case: scrolling windows full of lots and lots of client-side-rendered textIt's possible to compress this down to nothing using motion estimation; whether Wayland can actually implement that remains to be seen but it's not impossible.
Wayland and Weston 1.0 released Posted Oct 24, 2012 16:42 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]
That is EASILY fixed by a good compression protocol.
motion detection is not as easy as it should be Posted Oct 25, 2012 4:25 UTC (Thu) by amtota (guest, #4012) [Link]
Unfortunately that is not the case.
xpra.org uses x264 and vpx codecs to achieve great compression ratios (whilst still maintaining almost pixel perfect quality for our xterms), but even these codecs fail to detect scrolling when more than a few lines move at a time.
Now, we don't want to start writing our own motion detection code, and since the x11 server already knows about the motion, it would be nice if it could expose this information to us... sadly it does not.
motion detection is not as easy as it should be Posted Oct 25, 2012 11:24 UTC (Thu) by njs (guest, #40338) [Link]
The X server may or may not know about scrolling (it depends on which APIs the client is using), and the interface to expose this would be a nightmare... plus scrolling is an extremely trivial sort of motion to detect (integer number of pixels with absolutely unchanged contents). Why not just write some motion detection code?
Both sides of the connection have the old window contents available (though the server may not keep it in memory right now). A cheap-but-effective algorithm would be: Break this into fixed size chunks (say 16x16 pixels), discard solid-color ones, and hash the remaining with a rolling hash. When you get a new region to send, first run the rolling hash over this region to see if there are any matches. If so, align the new data with the matching old data, subtract, and send the offset + the difference (which will be highly compressible). Then the client inverts this to reconstruct. This will be effective even if some parts of the region are changing at the same time they scroll, new bits of the window are scrolling onto screen, etc., and the computational overhead would still be absolutely swamped by gzip, never mind vpx/x264.
motion detection is not as easy as it should be Posted Oct 25, 2012 15:34 UTC (Thu) by renox (subscriber, #23785) [Link]
>Why not just write some motion detection code?
Because the more complex compression you do, the more latency you add..
motion detection is not as easy as it should be Posted Oct 25, 2012 19:33 UTC (Thu) by njs (guest, #40338) [Link]
Yes, that's why I made a point of describing an algorithm that should only add a tiny amount of overhead on top of the existing gzip cost, and less than the super-fancy video encoders that are already used? Detecting simple scrolling is really not complicated.
motion detection is not as easy as it should be Posted Oct 25, 2012 19:51 UTC (Thu) by hoegsberg (guest, #57768) [Link]
Yeah, and we're working on more or less the exact rolling hash idea you described. It was kinda weird to see you describe the same approach here... It's still work in progress, but there's a few PNGs here that shows the current status: http://people.freedesktop.org/~krh/rolling-hash/
With just a few MULs per pixel, we can detect if a 32x32 blocks starting at that pixel appears in the previous frame. This should basically be as good as any scrolling/copyarea hint we could've gotten from X or a toolkit, and it detects duplicate blocks in may cases where applications don't scroll but just re-render (like resizing). And of course this technique applies to both fullscreen remote display or per-window remote display.
motion detection is not as easy as it should be Posted Oct 25, 2012 21:07 UTC (Thu) by njs (guest, #40338) [Link]
Hah, awesome. Well, I guess it's the obvious thing to try...
Wayland and Weston 1.0 released Posted Oct 24, 2012 17:40 UTC (Wed) by daniels (subscriber, #16193) [Link] The comment thread in https://lwn.net/Articles/481138/ has several instances of Wayland boosters doing down network-transparency as useless. Yeah, unfortunately I can't do anything about the armchair software developers. Everyone who's actually contributed to Wayland has always had the same answer: remoting's going to come, it'll be better than X, but it won't be part of the core protocol because we don't think that's the right approach. The FAQ is badly worded, but that'll get fixed.
Wayland and Weston 1.0 released Posted Oct 25, 2012 0:12 UTC (Thu) by nix (subscriber, #2304) [Link]
Agreed. I said 'boosters' not 'developers' for a reason :)
I suppose client-side remoting can fix this just as well as X can: the toolkit knows when you asked to print text, so can send just that over the wire perfectly well.
(It is disturbing to realise that in future different applications will have different degrees of support for remoting depending on what toolkit they're using, but I can't really claim that this differs from the current situation where they have different degrees of support for remoting depending on whether their developers ever tried to minimize roundtrips or whether they are using DRI. It's not as if 'it takes an hour for this program to map a window' is appreciably better than 'not working at all' -- and at least a 'just hurl giant bitmaps' fallback remoting program will work with everything, even if inefficiently.
I am slowly starting to be won over. Dammit. Can't you leave me *any* pointless irrational positions?
Wayland and Weston 1.0 released Posted Oct 25, 2012 4:00 UTC (Thu) by raven667 (subscriber, #5198) [Link]
> I am slowly starting to be won over. Dammit. Can't you leave me *any* pointless irrational positions?
It's a pleasure to converse with someone who is at least willing to consider another persons position. There are plenty if people here that only seem interested in complaining but not listening, they are not much fun to talk to.
Wayland and Weston 1.0 released Posted Oct 31, 2012 15:40 UTC (Wed) by daglwn (subscriber, #65432) [Link]
I too have started to come around on this now that it's been made clear that remote display will be possible.
I didn't understand the distinction between "remote display" and "remote transparency" until you clarified that earlier and stated that remote display is indeed a needed feature. Thank you for clearing that up for me.
Wayland and Weston 1.0 released Posted Oct 25, 2012 15:36 UTC (Thu) by gidoca (subscriber, #62438) [Link]
As far as I understand from the XDC presentation video, it wouldn't be implemented in the toolkit, but as a special wayland compositor. On the computer you want to display the window, you would run the regular weston compositor, plus some client software. On the machine the application runs on, you would instead run some special compositor that speaks the wayland protocol, but sends the buffer over the wire instead of displaying it on the local display. Therefore, you wouldn't need anything special in the toolkit. Note that I don't know any more than what I learned from the talk, so take this with a grain of salt.
Wayland and Weston 1.0 released Posted Oct 28, 2012 15:58 UTC (Sun) by nix (subscriber, #2304) [Link]
That's the fallback remoter, I think. The *real* remoting would be done in the toolkits, which know exactly what the application has done and can transmit data over the wire with correspondingly high efficiency, just as X does now only actually efficiently. (I hope there'll be a library of some sort implementing authentication and such things, so that the different toolkits don't end up with divergent ways of authenticating the remote connection with different user interfaces. xauth-plus-ssh is bad enough as it is...)
Wayland and Weston 1.0 released Posted Nov 1, 2012 19:22 UTC (Thu) by wmf (guest, #33791) [Link]
I think toolkit remoting is going to be much more complex (especially when you have to implement it N times) and not necessarily faster than bitmap remoting (cf. the Sun Labs SLIM project). Also, it creates more bad PR because it makes it look like Wayland remoting is five years away.
Wayland and Weston 1.0 released Posted Oct 30, 2012 21:09 UTC (Tue) by daglwn (subscriber, #65432) [Link]
> A killer for me, since my Emacs, with huge windows full of lots of text,
> is *always* run network-remote.\
I totally agree that remote display is an absolute must.
But have you tried Emacs with TRAMP? It's a pain to set up but once working I've found that it really does what I need to do: compile, debug, shell, etc.
There are some things TRAMP can't do so it's not a complete replacement for remote display but I've found I don't need remote display for Emacs anymore. Other things, sure, but not Emacs.
Wayland and Weston 1.0 released Posted Oct 31, 2012 0:38 UTC (Wed) by nix (subscriber, #2304) [Link]
I need it for Emacs simply because my remote always-on server is, well, always on, and I fairly often access my Emacs from remote sites via emacsclient while the desktop is off. (The desktop is a power sucker, so it goes off when I'm not using it.)
TRAMP is very nice, but without remote display I'd be left running my Emacs on a machine that was turned off, and not even Wayland can do that. :}
Wayland and Weston 1.0 released Posted Oct 31, 2012 15:43 UTC (Wed) by daglwn (subscriber, #65432) [Link]
Makes total sense to me. Our company has not yet seen always-on desktop systems as a power problem. Perhaps they will soon. :)
|
|||||||||||||