| |||||||||||||
Bad NIH, good NIHBad NIH, good NIHPosted Mar 8, 2013 23:58 UTC (Fri) 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)
I assume you're talking about Xorg.
> The problem is that the core protocol is old
That's not a problem. That's an advantage, which says that the protocol has such a good design that being old still works and supports all the modern features.
> imposes restrictions that cannot be avoided (e.g. slow startup due to multiple roundtrips) and 90% of it
That may be a problem. Let's check that:
$ time xterm -e /bin/true
Nope, that's not a problem too. :) Startup is fast enough.
If some programs start faster, while others start slower, then those programs are to blame, not Xorg, right?
(Log in to post comments)
Bad NIH, good NIH Posted Mar 9, 2013 4:41 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]
>That's not a problem. That's an advantage, which says that the protocol has such a good design that being old still works and supports all the modern features.
No, it doesn't.
For example, there's a long-standing problem with language switching by alt-shift keypress (not possible due to X quirks with modifier keys processing).
Then there's the whole full-screen rendering fiasco. There's no good way for an app to switch to a full screen and make sure the previous resolution is restored when the app exits.
Then there's a problem with OpenGL-based compositors - they don't always synchronize rendering correctly.
Etc.
Bad NIH, good NIH Posted Mar 9, 2013 19:50 UTC (Sat) by Serge (guest, #84957) [Link]
>> That's not a problem. That's an advantage, which says that the protocol has such a good design that being old still works and supports all the modern features.
> No, it doesn't.
> For example, there's a long-standing problem with language switching by alt-shift keypress (not possible due to X quirks with modifier keys processing).
Bad example.
> Then there's the whole full-screen rendering fiasco. There's no good way for an app to switch to a full screen and make sure the previous resolution is restored when the app exits.
First, it's a bad idea anyway, because if I changed resolution with `xrandr` I don't want it to change back when `xrandr` exits. Next, Xorg is able to "restore" whatever resolution you configure using Ctrl+Alt+GrayPlus and Ctrl+Alt+GrayMinus since forever. Also Xorg allows you to bind `xrandr` call with your favourite resolution to any hotkey. And finally, it STILL has nothing to do with X11 protocol.
> Then there's a problem with OpenGL-based compositors - they don't always synchronize rendering correctly.
That's not a bug, but optional feature. You can turn vsync off and see how many FPS you get. Good for benchmarks and regression testing. And this is still about compositing WMs, but it's not a bug of Xorg or X11 protocol.
No protocol problems found. :)
Bad NIH, good NIH Posted Mar 9, 2013 20:24 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]
>First, I'm not sure what's the problem you're talking about, can you explain in details?
Simple. There is no way for language switcher to use only modifier keys. X protocol itself doesn't support it and workarounds are too complicated (like getting grab on all input and re-inserting messages back).
>Next, what a strange choice for the keyboard layout hotkey, there're plenty of keys on a keyboard (CapsLock, Menu...) that are less used and easier to hit.
>First, it's a bad idea anyway, because if I changed resolution with `xrandr` I don't want it to change back when `xrandr` exits.
>Next, Xorg is able to "restore" whatever resolution you configure using Ctrl+Alt+GrayPlus and Ctrl+Alt+GrayMinus since forever.
...and here we have a wonderful example of X's "robustness"...
Bad NIH, good NIH Posted Mar 11, 2013 3:03 UTC (Mon) by Serge (guest, #84957) [Link]
> There is no way for language switcher to use only modifier keys. X protocol itself doesn't support it and workarounds are too complicated (like getting grab on all input and re-inserting messages back).
Just tried. I've set up xkb to switch layout using my Ctrl key. Looks working. I also configured xbindkeys to run some command when I press Shift. Looks working too. Both X11 protocol and Xorg itself allow you to use modifier keys to switch language, or write a custom switcher to do that.
> Duh. I think it's obvious that there should be a special protocol for resolution changing apps.
Ehm... Two protocols, one for games, changing resolution, and another for tools, changing resolution? And how are you going to stop games from using protocol for tools? Create another third protocol to authorize them? ;)
In Xorg there're much simpler solutions to that. I already told you about Ctrl+Alt+Plus/Minus and suggested you to bind `xrandr` call to some hotkey. Alternatively you can create a simple "restorer.sh" script:
#!/bin/sh
And run the game like: `restorer.sh thegame`
> And they do not always work. Besides, I don't _have_ a gray minus on my keyboard.
You don't have Numpad? Weird keyboard... Well, you can still get that key! You can remap any of your keys using `xmodmap`.
> ...and here we have a wonderful example of X's "robustness"...
Yeah. Xorg is great, it allows you use whatever use-case you want. It's much better than Wayland, where features like that are impossible.
Bad NIH, good NIH Posted Mar 11, 2013 4:01 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]
>Just tried. I've set up xkb to switch layout using my Ctrl key. Looks working.
That's because ctrl key is not a modifier key, try that with alt-shift.
It's actually possible to use alt-shift for switching, but not easily. As far as I remember, that involves editing xkb bindings to remap this combination to another.
Decidedly not an example of X's robustness.
>Ehm... Two protocols, one for games, changing resolution, and another for tools, changing resolution?
>And how are you going to stop games from using protocol for tools? Create another third protocol to authorize them? ;)
Changing resolution is a privileged operation that shouldn't be exposed to games. In fact, games just need a way to hint the composer that they want to occupy the full screen (maybe with a specific screen resolution). For example, Mac OS X in these cases allocates a separate _desktop_ and switches to it, leaving other desktops untouched.
>In Xorg there're much simpler solutions to that. I already told you about Ctrl+Alt+Plus/Minus and suggested you to bind `xrandr` call to some hotkey. Alternatively you can create a simple "restorer.sh" script
Sorry, but using shell scripts to restore resolution belongs in early 90-s.
> You don't have Numpad? Weird keyboard...
>Well, you can still get that key! You can remap any of your keys using `xmodmap`.
Bad NIH, good NIH Posted Mar 11, 2013 5:46 UTC (Mon) by Serge (guest, #84957) [Link]
> That's because ctrl key is not a modifier key
...
> It's actually possible to use alt-shift for switching, but not easily. As far as I remember, that involves editing xkb bindings to remap this combination to another.
What? "alt_shift_toggle" is among standard xkb options. And most DEs allow you to choose it. What DE are you using?
> Yep. And it's actually already done!
Reimplementing (theoretically) one more feature from Xorg in Weston does not make Weston better than Xorg. And it's still impossible to do that using Wayland protocol.
> Yep. Just making wlrandr privileged is enough.
That would also make xrandr-like tools impossible, so we get back to the original problem. Or what do you call "privileged"?
> For example, Mac OS X in these cases allocates a separate _desktop_ and switches to it, leaving other desktops untouched.
They took that idea from X server. :-) Among the first links in google:
> Sorry, but using shell scripts to restore resolution belongs in early 90-s.
That was just one option among many. Xorg gives you the choice. You don't have even that option in Wayland.
> I don't care. Anything that doesn't work out-of-box is unacceptable.
Sorry, but restoring the resolution when user have not asked for is stupid. What if user have intentionally changed the resolution? ;-)
The entire idea of changing the resolution back when program exits is actually pointless. It solves nothing. Program can just change resolution and freeze or go into background.
And this is not a problem of X11/Xorg anyway. X11 allows you to implement whatever solution you like.
Bad NIH, good NIH Posted Mar 11, 2013 6:35 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]
> What? "alt_shift_toggle" is among standard xkb options. And most DEs allow you to choose it. What DE are you using?
KDE. Using xkb options results in some strange behavior. Also, hotkeys involving alt-shift are sometimes garbled (i.e. you press alt-shift-k and it results in switching keyboard layout and printing 'л'). I moved to CapsLock for layout switching eventually.
> Reimplementing (theoretically) one more feature from Xorg in Weston does not make Weston better than Xorg. And it's still impossible to do that using Wayland protocol.
>They took that idea from X server.
Virtual desktops on Mac OS X are the same thing as virtual desktops on X. And Mac OS X allows virtdesktops on a same display to have different resolutions (which X doesn't allow, btw).
> That was just one option among many. Xorg gives you the choice. You don't have even that option in Wayland.
Wayland is so great because is designed from the start to BE RELIABLE in the modern world. That's why Wayland devs pay a lot of attention to details that you simply don't know about.
For example, X still has problem with subpixel rendering because there's no way for the client-side library to know the current display's orientation. That's why KDE and GNOME have separate manual settings for them, while Wayland carries this information in the native protocol.
Then there's a whole question of synchronization. Wayland devs spent quite a lot of time discussing the whole double buffering mechanism, making it much more robust than in X (where buffer swap either stalls your pipeline or can happen at indeterminate time).
Bad NIH, good NIH Posted Mar 11, 2013 15:15 UTC (Mon) by nye (guest, #51576) [Link]
>For example, X still has problem with subpixel rendering because there's no way for the client-side library to know the current display's orientation. That's why KDE and GNOME have separate manual settings for them, while Wayland carries this information in the native protocol.
What happens - either in X or Wayland - if one window spans displays which are not in the same orientation?
This monitor setup is not a hypothetical scenario for me BTW.
(And as an aside, I still think subpixel font rendering is a totally stupid idea, in part because of this very issue which means that the font renderer needs to have precise knowledge about the specific output device at any time; that sounds to me a lot like 'unwarranted chumminess with the implementation'. Leave aside what happens if there are any display transformations in effect, or if you want to create screenshots, or...)
Bad NIH, good NIH Posted Mar 11, 2013 15:20 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]
> What happens - either in X or Wayland - if one window spans displays which are not in the same orientation?
One kind of rendering would be used.
Wayland has no notion of displays, really. An application just gets a surface to paint on, which might or might not span several displays. In case of multi-display surface Wayland can use 'unknown' subpixel ordering.
> And as an aside, I still think subpixel font rendering is a totally stupid idea, in part because of this very issue which means that the font renderer needs to have precise knowledge about the specific output device at any time
Bad NIH, good NIH Posted Mar 12, 2013 13:31 UTC (Tue) by nye (guest, #51576) [Link]
>In case of multi-display surface Wayland can use 'unknown' subpixel ordering.
Do you know if commonly available font renderers will automatically disable subpixel rendering in the case that they don't know the order of the subpixels?
(Not that there's any particular reason you should know, bu this is the first time I've even seen anyone bring up this issue in Wayland discussion which kind of implies you've at least thought about it more than most.)
>Uhm. It has this knowledge in 99% of cases.
But not in X, you previously said?
>And personally I prefer occasionally looking at blurred screenshots rather than looking at blurred text _all_ the time.
I'm not quite clear on that - subpixel rendering is an attempt to make text closer to its theoretically correct shape in exchange for making it less sharp, so I can't see how it could possibly make text *less* blurred than without it.
The entire theoretical basis of subpixel rendering is flawed because it relies on the fact that the colour perception of the eye is less accurate than its ability to discern the intensity. To rephrase that: your eye can discern the improved shape while not noticing the colour change.
This is true to an extent, but in the centre of the eye the colour perception is good enough that in practice there's visible colour fringing in subpixel rendered text unless you either have a very high-dpi display, or you're sitting miles away. I know a lot of people don't mind that and find the trade-off worthwhile, but I most definitely am not among them.
Bad NIH, good NIH Posted Mar 12, 2013 14:19 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]
> Do you know if commonly available font renderers will automatically disable subpixel rendering in the case that they don't know the order of the subpixels?
Right now? I don't think so, as there's no support for getting subpixel order in X.
But it shouldn't be complicated to add if there's a way to obtain surface subpixel layout information.
>But not in X, you previously said?
>I'm not quite clear on that - subpixel rendering is an attempt to make text closer to its theoretically correct shape in exchange for making it less sharp, so I can't see how it could possibly make text *less* blurred than without it.
If you want to have completely 'sharp' fonts then you have to use 100% on/off pixels with the same intensity for all of their subpixels. So in this case subpixel information is irrelevant (unless you also want to do _colored_ text). But completely 'sharp' fonts also look too jagged and any attempts on smoothing that don't take subpixel ordering into account are going to result in a total mess.
I don't think that color fringing is a big problem for most people. Personally, all of my display devices are now at Retina resolution or close to it :)
Bad NIH, good NIH Posted Mar 12, 2013 22:15 UTC (Tue) by Serge (guest, #84957) [Link]
> there's no support for getting subpixel order in X.
> Subpixel rendering allows to draw better looking curves by taking into account the fact that physical pixels on the screen consist of discrete subpixels.
Here you're wrong. Twice. Both X11 and Wayland provide that information. But the fun part: it is useless in Wayland. By design. Because in Wayland your surface could be rotated, stretched or somehow transformed, so that subpixel information is completely useless there. That's the Wayland protocol with its great "reliable" design.
Bad NIH, good NIH Posted Mar 13, 2013 1:41 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]
>Here you're wrong. Twice. Both X11 and Wayland provide that information.
Nope. X protocol knows nothing about subpixel order. Wayland does.
Xranrd in this case is a cop-out because it's not universally available.
>But the fun part: it is useless in Wayland. By design. Because in Wayland your surface could be rotated, stretched or somehow transformed, so that subpixel information is completely useless there.
And of course, there are compositing managers in X that can mutilate the image in various ways.
Bad NIH, good NIH Posted Mar 14, 2013 5:38 UTC (Thu) by Serge (guest, #84957) [Link]
> Nope. X protocol knows nothing about subpixel order. Wayland does.
Both X and Wayland request information from display. If that information is available there they can read it. Both. Or do you thing that Wayland is reading the mind of display creators, while Xorg can't do that? ;-)
> Xranrd in this case is a cop-out because it's not universally available.
Run `xrandr --verbose` and see "Subpixel" there. Now think, if xrandr gets information from X-server then X-server knows about subpixels, and X11 protocol is able to transfer that, right? Just read the protocol if you still don't believe me.
> Wayland exposes the surface orientation to applications (surprise!)
Indeed, it's a surprise, could you point me to that part of the Wayland protocol?
Bad NIH, good NIH Posted Mar 14, 2013 5:45 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
> Both X and Wayland request information from display. If that information is available there they can read it. Both. Or do you thing that Wayland is reading the mind of display creators, while Xorg can't do that? ;-)
Yep. Try that trick with Xrandr on legacy NVidia drivers (hint: it doesn't work).
Of course, your app can also read display EDIDs and parse them. Through the X protocol! But that kinda says that you should probably stop doing it.
> Run `xrandr --verbose` and see "Subpixel" there.
>cyberax@whale2:~$ xrandr --verbose
Yeah, robust X protocol and all that....
> Indeed, it's a surprise, could you point me to that part of the Wayland protocol?
Bad NIH, good NIH Posted Mar 14, 2013 8:35 UTC (Thu) by Serge (guest, #84957) [Link]
> cyberax@whale2:~$ xrandr --verbose
> SZ: Pixels Physical Refresh > *0 1024 x 768 ( 260mm x 195mm ) *60 > ... > Yeah, robust X protocol and all that....
Ha-ha, that was fun. Either you have done that on purpose, or you're testing that on a server back from 2005. :-) You can check `xdpyinfo -ext RENDER` too, it's supported since about 2003.
Xrandr is just a tool to request that information. Xdpyinfo is another one. X-server knows about subpixels and uses them for a loooong time.
> Try that trick with Xrandr on legacy NVidia drivers (hint: it doesn't work).
Why do you think it won't work? Hah! Try Wayland with legacy NVidia driver (hint: it doesn't work)!
> See "enum transform" and various related events and requests
Have you seen that yourself? It's just display rotation, similar to xrandr, not the surface rotation done by compositor.
Bad NIH, good NIH Posted Mar 14, 2013 10:59 UTC (Thu) by nye (guest, #51576) [Link]
>You can check `xdpyinfo -ext RENDER` too, it's supported since about 2003.
"Screen 0 (sub-pixel order Unknown)"
i915 driver FWIW.
Bad NIH, good NIH Posted Mar 14, 2013 17:31 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
Can you provide a reference to X specification about subpixel order and its relationship with display transformation? And not for xrandr, please.
Bad NIH, good NIH Posted Mar 15, 2013 7:15 UTC (Fri) by Serge (guest, #84957) [Link]
> Can you provide a reference to X specification about subpixel order and its relationship with display transformation? And not for xrandr, please.
Bad NIH, good NIH Posted Mar 15, 2013 16:04 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]
That's an extension, not the X protocol itself.
Bad NIH, good NIH Posted Mar 16, 2013 0:15 UTC (Sat) by HelloWorld (guest, #56129) [Link]
Yes, that's true. It also doesn't matter at all.
Bad NIH, good NIH Posted Mar 16, 2013 7:22 UTC (Sat) by Serge (guest, #84957) [Link]
> That's an extension, not the X protocol itself.
In X world extensions are part of the X11 protocol. For example this particular extension is part of X11R6.9, you can see that in its URL.
Bad NIH, good NIH Posted Mar 16, 2013 9:08 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]
But it's not a part of my X server.
Waaahhhh! X encourages fragmentation!
Bad NIH, good NIH Posted Mar 12, 2013 21:21 UTC (Tue) by Serge (guest, #84957) [Link]
> Using xkb options results in some strange behavior. Also, hotkeys involving alt-shift are sometimes garbled (i.e. you press alt-shift-k and it results in switching keyboard layout and printing 'л').
Well, you switched layout and pressed some key... Anyway, that's not X11 problem, just a bug in xkb in worst case. And it's not solved by Wayland (you probably don't know but Wayland/Weston kind of uses xkb :)). But if that's a bug it should be fixed. Just curious, what is expected behavior for you?
> So it's impossible even when I'm pointing to you that it IS already done? And using a Wayland protocol extension.
What you linked is same as what you have with Xorg, and don't like so much. :) And that's a compositor extension (suggested, since it's not a part of weston), it's not part of Wayland protocol. Wayland compositor is like HelloWorld program, you can extend it to do everything you want. But it will be supported by that compositor only.
It is one of the greatest problem of the entire Wayland design — it encourages you to put every missing feature into unique compositor extension, so you eventually end up with lots of incompatible compositors, each having a small subset of all the Xorg abilities and standards.
> Virtual desktops on Mac OS X are the same thing as virtual desktops on X. And Mac OS X allows virtdesktops on a same display to have different resolutions (which X doesn't allow, btw).
Virtual desktops on X are up to the window manager. Nothing stops it from switching resolution when you switch desktop. So again, that's not X11 problem.
> I don't care about many options. I want a display stack that works consistently and predictably in most cases.
Then what stops you from configuring it the way you want? X allows you to do that, Wayland/Weston does not.
> Wayland is so great because is designed from the start to BE RELIABLE in the modern world.
It's not designed to "be reliable". :) Sorry. It basically designed to be "like X but better". On the other hand X is reliable, because it allows you to configure it the way you want, and it will work that way for years.
> For example, X still has problem with subpixel rendering
What problem?
> because there's no way for the client-side library to know the current display's orientation. That's why KDE and GNOME have separate manual settings for them, while Wayland carries this information in the native protocol.
So does X. Check `xrandr --verbose`. (Oops) :) KDE and GNOME just allow you to configure some Xft/fontconfig options manually, because many (most?) monitors actually do not provide that information. And because some people don't like subpixel font hinting. Would you prefer it to be unconfigurable?
> Then there's a whole question of synchronization. Wayland devs spent quite a lot of time discussing the whole double buffering mechanism, making it much more robust than in X (where buffer swap either stalls your pipeline or can happen at indeterminate time).
(You talk about that as if you never used Wayland/Weston and never seen how windows blinked like crazy when you resized them) It's not that I understand what problem you talk about but who cares? Yes, Wayland is a lot about "we don't like how X does that so we do that differently", but who cares? Nobody works on that low level. And those who do (authors of toolkits and compositing managers) have already implemented that ten years ago. What's the point in changing the protocol that people either don't care or got already implemented and working?
Bad NIH, good NIH Posted Mar 13, 2013 8:04 UTC (Wed) by paulj (subscriber, #341) [Link] Virtual desktops on Mac OS X are the same thing as virtual desktops on X. And Mac OS X allows virtdesktops on a same display to have different resolutions (which X doesn't allow, btw). My multi-monitor setup in work consists of two different sized monitors. I run each at their native res. So I have desktops with 2 different resolutions right in front of me, here now. So I strongly suspect you may be wrong on this point.
Bad NIH, good NIH Posted Mar 11, 2013 22:58 UTC (Mon) by khc (subscriber, #45209) [Link]
> That's because ctrl key is not a modifier key, try that with alt-shift.
I use alt-shift to switch input method (with scim), and have been doing this for a few years. Other than me accidentally hitting it from time to time, I don't have a problem with it.
Bad NIH, good NIH Posted Mar 9, 2013 16:01 UTC (Sat) by nix (subscriber, #2304) [Link]
Um, startup is fast on low-latency connections, sure. Now try it over a higher-latency link. Be prepared to wait a while (sometimes *minutes*, not seconds: 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).
Bad NIH, good NIH Posted Mar 9, 2013 19:10 UTC (Sat) by Serge (guest, #84957) [Link]
> 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. :)
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.
Bad NIH, good NIH Posted Mar 11, 2013 14:40 UTC (Mon) by nye (guest, #51576) [Link]
$time /bin/true
real 0m0.004s user 0m0.000s sys 0m0.004s
$time xterm -e /bin/true
$ssh <remote-machine>
$time /bin/true
$time xterm -e /bin/true
In this example, <remote-machine> is at the end of an ADSL connection, with an RTT of around 45ms - ie. about the best kind of connection that's widely available for the kind of money that individuals and small organisations can afford (and if you think a couple of grand a month for an internet connection is affordable, you're not thinking 'small organisation').
Bad NIH, good NIH Posted Mar 11, 2013 17:29 UTC (Mon) by sfeam (subscriber, #2841) [Link]
You (or xterm) are doing something very wrong.
Here's what I get using ssh to a remote machine over a bog-standard comcast consumer cable connection, followed by display of not just a terminal window but full graphics display plus round-trip response to a mouse click. Some toolkits are better than others at negotiating fast response over a remote connection, but all are funneled through x11.
$ssh <remote-machine>
$time gnuplot -e 'set term qt; plot x; pause mouse'
$time gnuplot -e 'set term wxt; plot x; pause mouse'
$time gnuplot -e 'set term x11; plot x; pause mouse'
and here's the time for display only (no wait for mouse click):
$time gnuplot -e 'set term x11; plot x'
That's not to say that response couldn't be improved, but your 37 second latency is horrible for some reason other than x11.
Bad NIH, good NIH Posted Mar 11, 2013 23:07 UTC (Mon) by nix (subscriber, #2304) [Link]
I bet his connection is dropping packets, so there's an extra delay caused by TCP timeouts in there.
Bad NIH, good NIH Posted Mar 12, 2013 12:50 UTC (Tue) by nye (guest, #51576) [Link]
>I bet his connection is dropping packets, so there's an extra delay caused by TCP timeouts in there.
Nope, but there is something interesting to see from the ping statistics while this is going on:
118 packets transmitted, 118 received, 0% packet loss, time 117123ms
(Obviously this also covers some time before and after.)
Curious as to why my ping time goes up to several hundred ms while xterm is launching, I've discovered that this local machine feels the need to send a few megabytes of data to the remote machine before doing anything.
In fact, it looks like xterm is the culprit here. I don't have many X clients installed on the machine I'm ssh'ing into to test with, but xfontsel at least starts up a lot quicker (a couple of seconds).
If even xterm can't get X network transparency right, what hope is there for everyone else?
Bad NIH, good NIH Posted Mar 14, 2013 5:48 UTC (Thu) by Serge (guest, #84957) [Link]
> You (or xterm) are doing something very wrong.
You can check that using x11trace tool. Most of the time is taken by sending fonts and other settings. That increases startup time, but makes it work faster, because it does not have to send images, it can reference fonts on the server side.
Xterm is smarter than most people think. It has configurable fonts, colors, hotkeys and many other options. For example to see xterm menu hold Control+Left/Right/Middle mouse button. But the point is that those settings are stored on a server-side (XResource), and xterm reads them all from server during startup.
Some DEs are using that. For example on KDE xterm colors should match your theme, does not matter what host you start xterm from. That's the server-side themes in action. Nobody remembers them any more... (sigh)
Bad NIH, good NIH Posted Mar 14, 2013 5:43 UTC (Thu) by Serge (guest, #84957) [Link]
> $time xterm -e /bin/true
> real 0m0.359s > user 0m0.032s > sys 0m0.036s
Wow. I couldn't get it that slow even on a slowest Intel Atom netbook I could find. Was that the worst test of many?
Anyway, your samples confirm that running application remotely is slower than running it locally. That was obvious even without testing. :) If you wanted to say that applications should start faster under Wayland than under Xorg, you should test something like:
$ time xterm
$ time weston-terminal
But even that test does not necessary mean that X is faster than Wayland. It just means, that xterm starts faster. Both times are good enough. And X11 is not a bottleneck for faster program startup time. If you actually need faster startup over network right away you can try winswitch.org/xpra.
PS: When benchmarking some soft do multiple tests and select the best result. Also don't forget to switch cpufreq governor to "performance" otherwise you're benchmarking your governor, not your soft.
Bad NIH, good NIH Posted Mar 14, 2013 11:24 UTC (Thu) by nye (guest, #51576) [Link]
>Wow. I couldn't get it that slow even on a slowest Intel Atom netbook I could find. Was that the worst test of many?
No, but many repeated runs do bring it down to 0.109s in the best case.
To be fair, I don't know if the video device and driver in use have any bearing on this, but just in case it does it's worth noting that I'm running on a laptop with Intel integrated graphics, where I have historically found the quality of both hardware and driver ranges from 'awful' to 'unspeakably awful'.
> If you wanted to say that applications should start faster under Wayland than under Xorg, you should test something like:
I just wanted to disagree with your claim that slow startup is not an issue, because it very frequently is when you are running remote X clients. It happens that the example you picked was one that demonstrated the difference particularly clearly.
Bad NIH, good NIH Posted Mar 15, 2013 9:01 UTC (Fri) by Serge (guest, #84957) [Link]
> No, but many repeated runs do bring it down to 0.109s in the best case. I think this is an example where the first case is the relevant one though, because that's what you'd experience in real use.
It depends on what do you want to benchmark. If you're just curious "how fast would it be next time I try" then yes. But if your goal is to compare two programs then you must reduce impact of all other obstacles, i.e. cpu throttles, disk cache, memory/swap, other programs running, etc.
> I just wanted to disagree with your claim that slow startup is not an issue, because it very frequently is when you are running remote X clients. It happens that the example you picked was one that demonstrated the difference particularly clearly.
I was just trying to say that "core protocol imposes restrictions that cannot be avoided (e.g. slow startup due to multiple roundtrips)" is not true. Slow startup is not X11 issue when running locally. Wayland only makes things worse. Applications would ofter start slower on Wayland because they're expected to talk to hardware, which requires additional steps for hardware initialization.
As for remote startup it's not that fast because of software, not because of protocol limitations. For example it could be much faster if xterm was sending requests in batch instead of waiting for response every time before sending another request. But people are lazy... They don't like optimizing things. But they like rewriting things from scratch somewhy. It's not a problem of X11 protocol, it's a human problem.
|
|||||||||||||
