LCA: The ways of Wayland
Posted Feb 14, 2013 0:09 UTC (Thu) by khim
In reply to: LCA: The ways of Wayland
Parent article: LCA: The ways of Wayland
On the subject of remote displays, I've long thought the best way to handle remote applications is, rather than copying bitmaps back and forth, is to handle it at the toolkit level.
Sure, that's doable. I'm pretty sure some programs will allow you to do that. Probably the same percentage of them which allow you do connect to the new X server on the fly (as emacs can do).
For all other uses there will be need to do something different.
You already explained why it works just fine and will continue to work or why it fails and will continue to fail (depending on your viewpoint). Applications which need this today are already implemented this way with a web 2.0. Applications which don't need that will not have that because... well, they don't need it. It's like an OpenBSD support: something you can to your program but which will be broken all the time without anyone noticing or caring.
I don't really see why do you think it'll be a problem to achieve acceptable speed with a bitmaps and a compression: if you have slowly changing stuff on your screen then delta-algorithms will work fine and if you have something like 3D shooter you'll need to send huge amount of data anyway. The only case where I can imagine substantial loss is with videoplayers: if you send pre-compressed stream (which was compressed using state-of-the-art-algorithms which need insane computation requirements of course it'll be more efficient then if you'll compress these same frames on-the-fly), but this is such a narrow use case I doubt we need optimize for it (or, alternatively, it may be good idea to provide sensible bypass for it because it's extremely narrow but quite common case).
to post comments)