Recent Features
| |||||||||||||
Bad NIH, good NIHBad NIH, good NIHPosted Mar 9, 2013 19:10 UTC (Sat) by Serge (guest, #84957)In reply to: Bad NIH, good NIH by nix Parent article: Canonical reveals plans to launch Mir display server (The H)
> Um, startup is fast on low-latency connections, sure. Now try it over a higher-latency link.
That example doesn't add points to Wayland because in cases when you actually need that (rare cases, like running Oracle GUI installer on a server without a video card on board) you can still make it work faster under Xorg (vnc, xpra, etc.) but you can't make it work at all under Wayland, since you can't start Wayland compositor there.
> the worst I've ever encountered was over a dialup modem and took more than half an hour to map a window, though admittedly that was a program that took a couple of seconds to map its first window even on Ethernet
Still if it's slow for some programs but fast for others, then those programs are to blame, not Xorg, right?
In that particular case I would try selecting simple widget theme on a server side for that slow program, without nice gradients, cool round buttons or realistic shadows. :)
(Log in to post comments)
Bad NIH, good NIH Posted Mar 9, 2013 20:01 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]
> but you can't make it work at all under Wayland, since you can't start Wayland compositor there.
Wayland works just fine with purely software rendering ( http://www.phoronix.com/scan.php?page=news_item&px=OD... ). I'm not sure this support hasn't bitrotted since then, but there are certainly no fundamental reasons why Wayland should require graphics hardware at all.
Bad NIH, good NIH Posted Mar 9, 2013 20:17 UTC (Sat) by Wol (guest, #4433) [Link]
aiui, the X protocol REQUIRES that the video display is copied between the client and the server SEVERAL times.
If both are on the same machine, no problem. It's easy (and has been done) to do the copy by passing a pointer. Quick and simple.
However, I REGULARLY run KDE as a client on my linux machine, with the X server on either a different linux box, or my Windows laptop. SLOW SLOW SLOW. Slower than a spaced out sloth.
Cheers,
Bad NIH, good NIH Posted Mar 10, 2013 10:42 UTC (Sun) by nix (subscriber, #2304) [Link]
No, it doesn't require copying the video display at all. It requires protocol roundtrips (request/response), though, before the window is even mapped: and if the client is badly written it can require a *lot* of them. And there are a lot of badly written clients, since all too many people don't bother to test their programs on remote X at all, brushing off bug reports from people like me with "don't do that then".
Bad NIH, good NIH Posted Mar 10, 2013 11:01 UTC (Sun) by dlang (✭ supporter ✭, #313) [Link]
the many round trips at startup are largely to figure out what options are supported on the display side (since X has existed so long, may 'obvious' things, like color, are optional), and a substantial part of the speedup that approaches like nx provide is to short circuit these round trips.
This is very similar to what the 'wan accelerator' appliances do to the windows networking protocol to make it tolerable over high latency links (same problem, too many round trips)
While the fashion right now is for every app to render things as a complete bitmap, that's just a fashion of what is considered 'good' this year, that swings back and forth over time, in part depending on the available processing power at each end.
Bad NIH, good NIH Posted Mar 10, 2013 20:17 UTC (Sun) by raven667 (subscriber, #5198) [Link]
> While the fashion right now is for every app to render things as a complete bitmap, that's just a fashion of what is considered 'good' this year, that swings back and forth over time, in part depending on the available processing power at each end.
Think this statement is a gross mischaractization of the last 30+ years of graphics development with a history of hard won experience with apps, operating systems and hardware that can't be hand-waved away as mere "fashion". Where is the yearly "swing" in the evolution of serial terminals to framebuffers to fixed function accelerators to programmable GPUs, which has taken decades? If there is anything cyclic, computing has existed for too short a time to see it
The best you can say is that the approach of sending high level drawing commands across the wire like X or NeWS is what is being implemented with HTML5 applications using JS, DOM, CSS and WebGL
Bad NIH, good NIH Posted Mar 11, 2013 4:13 UTC (Mon) by Serge (guest, #84957) [Link]
> aiui, the X protocol REQUIRES that the video display is copied between the client and the server SEVERAL times. If both are on the same machine, no problem. It's easy (and has been done) to do the copy by passing a pointer. Quick and simple.
It does not. Quite the contrary it encourages you to pass your images to the server and manipulate them using "pointers". And of course Xorg has local display optimisations. It's up to the application what and how to draw. A lot of small unique images to pass over the network may slow down the whole process, as many modern themes do.
Simpler themes help. Drawing something like http://www.zimagez.com/zimage/2012-03-30--1333132280.php over network is much easier than something like http://4.bp.blogspot.com/-Ezze7Ar8OQ4/TaRaTjLLh5I/AAAAAAA...
> However, I REGULARLY run KDE as a client on my linux machine, with the X server on either a different linux box, or my Windows laptop. SLOW SLOW SLOW. Slower than a spaced out sloth.
It's slow compared to what? xpra/winswitch.org? NX? VNC? There're many options under X.
|
|||||||||||||
