| |||||||||||||
Bad NIH, good NIHBad NIH, good NIHPosted Mar 6, 2013 23:26 UTC (Wed) by nix (subscriber, #2304)In reply to: Bad NIH, good NIH by mmarq Parent article: Canonical reveals plans to launch Mir display server (The H)
maintains the X standard but is flexible enough to allow some extensibilityEr, you do know that X has had support for protocol extensions for about a quarter of a century now, right? Eventually it's just not enough. X has had an astonishing record of backward compatibility, but you can't drag an old horse forever, alas. Most of X is now unused by most applications, and there are things extensions just can't do :(
(Log in to post comments)
Bad NIH, good NIH Posted Mar 7, 2013 14:51 UTC (Thu) by mmarq (guest, #2332) [Link]
Think about Linux kernel...
Perhaps is not a good idea to drag an hold worse forever lol (not as old as X but pretty old). If only it was as easy to fork or start allover as X...
That is another cliche, there is no piece of software that can't be improved... only if wisdom "emperator", then things could be different, and anyone is "free" to fork the linux kernel or start a new one if they wish, only what is more prevalent at this low levels is quality and usefulness, *old* means nothing...
Bad NIH, good NIH Posted Mar 8, 2013 14:55 UTC (Fri) by nix (subscriber, #2304) [Link]
The problem is not that the software is old: software, indeed, does not rot. The problem is that the core protocol is old, imposes restrictions that cannot be avoided (e.g. slow startup due to multiple roundtrips) and 90% of it (probably more actually) is unused by everything you run, unless you really like running old Xaw-based paint programs. The protocol was very well-designed for its time, but its time was when PostScript was new: the designers couldn't foresee what was coming in graphics card design twenty years down the road. That sort of thing cannot be fixed without breaking protocol compatibility, by which point you're talking breaking every X app anyway. So why not try something quite different?
(I still think that a display protocol was a very important innovation and that making drawing direct to the framebuffer the core operation is a huge step back. But, hey, I'm not writing the code.)
Old software Posted Mar 8, 2013 15:13 UTC (Fri) by man_ls (subscriber, #15091) [Link] Software ages like any other human construct: style rules change, coding standards improve (and sometimes regress), libraries become unsupported and stop working on modern systems. Anyone who has tried to build software that is 20 years old can attest to it -- we are talking about the days when Linux was not yet two years old.That is of course a metaphor: while the code itself does not change with time, the world around it does. So in effect old code is as hard to use as other old tools.
Old software Posted Mar 8, 2013 19:04 UTC (Fri) by hummassa (subscriber, #307) [Link]
> Software ages like any other human construct: style rules change, coding standards improve (and sometimes regress), libraries become unsupported and stop working on modern systems. Anyone who has tried to build software that is 20 years old can attest to it -- we are talking about the days when Linux was not yet two years old.
> That is of course a metaphor: while the code itself does not change with time, the world around it does. So in effect old code is as hard to use as other old tools.
Kudos. Two EPIC paragraphs describing bitrot. I will quote you for ever and ever more, or at least until your quote is no longer pertinent. :-D
Bad NIH, good NIH Posted Mar 8, 2013 19:24 UTC (Fri) by HelloWorld (guest, #56129) [Link] I still think that a display protocol was a very important innovation and that making drawing direct to the framebuffer the core operation is a huge step back.I don't see why. Afaics, there were essentially two reasons for putting the rendering code in the X server:
Bad NIH, good NIH Posted Mar 9, 2013 0:21 UTC (Sat) by Serge (guest, #84957) [Link]
> Afaics, there were essentially two reasons for putting the rendering code in the X server
X server supports both client-side and server-side rendering.
But Xorg is much more than just rendering.
(#6 is not that strong now, Wayland fans talk a lot about Xorg being bad, and that gives some bad points to Xorg and commercial Linux development, sigh...)
At the same time X11 was never rotten. On the contrary, it was always among the first to innovate. First remote graphical terminals, first desktops with multiple workspaces, multi-monitor systems, first multiseats, first 3D-desktop, first multi-touch (MPX, yeah, it was done before iPhone :)) — most (if not all) of these things were first done under X-server.
> Otoh, client-side rendering is faster because it avoids the protocol overhead
You should probably like DirectFB a lot. It's direct, client-side, and has no server, so it completely avoids any overhead possible. :)
Bad NIH, good NIH Posted Mar 9, 2013 18:45 UTC (Sat) by HelloWorld (guest, #56129) [Link]
Bad NIH, good NIH Posted Mar 9, 2013 21:58 UTC (Sat) by Serge (guest, #84957) [Link]
> 1. Nobody needs or wants X servers for Windows, Mac OS or Android.
Have you heard about windows program called "putty"? You can ssh with it to remote server with no video adapter and run X11 apps over it. How? Using X server for Windows. You can do similar things with OS X, it has its own X server. There're also X11 implementations for Android.
Yes, people need and want X server for Windows, Mac OS and Android. And they have it.
> What people want is remote applications, and they'll get those with Wayland via a VNC-like protocol. Which, by the way, works way better than X for today's applications.
You don't need Wayland to use VNC, you know that? Also, Wayland is about direct client-side hardware use, you'll get some problems when you try using it on a server with no graphical hardware.
So, you have Xorg (works always, supports X11 forwarding, VNC, xpra, NX), and you have Wayland (works sometimes, theoretically supports VNC). I don't see a reason to choose Wayland in this case, do you?
> 2. It doesn't run everywhere. Android doesn't use it, Firefox OS doesn't, Tizen doesn't, Mac OS X and iOS don't, nobody right in their mind uses it except as a compatibility crutch.
It does run everywhere. It can be run on Android (and it was done since first androids), there're X11 implementations for iOS, and it's included in Mac OS X. Also it's used by Maemo/Meego.
> 3. That will come for Wayland as well, it's just a matter of time.
Wayland design makes me think it won't. What makes you think it will? Let's take an example: directfb. It's well known, was created 12 years ago (!) and still does not have those good tools.
> 4. You can run any desktop environment on Wayland too, and you can combine any Wayland compositor with any desktop, provided it offers the needed functionality (which obviously applies on X11 as well)
Theories again? Please, run Compiz on Wayland. At least run IceWM on Wayland. Have you ever used Wayland/Weston yourself?
> 5. The toolkits that matter will soon support Wayland (or already do)
I guess you have not seen how it looks. Try it. Anyway, all toolkits already support X11. Name one reason why they should bother supporting Wayland?
> 6. The Wayland protocol is stable
You obviously have no idea what's "stable". "Stable" means that I can release program today and it will continue to work. "Stable" means good for long term commercial use.
X11 is stable. It always was. Now Wayland has v1 protocol for a few months and you can't be sure that tomorrow there won't be Wayland v2 with completely different protocol. Bear in mind that currently you can't use Wayland protocol without compositor extensions. And a few existing compositors have them different. Wayland is unstable itself and it's trying to shake Xorg by constantly attacking it ("it can't be worse than X11"). This is bad for the entire Linux community.
> and X applications are supported via XWayland.
You haven't ever used it, have you? Try using RebeccaBlackOS LiveCD. When you notice that your X11 programs don't start any more try debugging that.
> That's why many of the X.org developers themselves (including Keith Packard, Kristian Høgsberg, Daniel Stone) support Wayland. Now please don't try to tell me that you know better than them what a future-proof graphics stack looks like...
Oh, that's the biggest mystery for me. Initially I thought that Wayland was just a proof-of-concept, like "Look, Linux has such a powerful graphical stack that I can easily create a simple window system". Then I thought that Wayland could be a test of new ideas before including them into Xorg. But Wayland is still promoted as being better than Xorg, and I don't see who it's supposed to be good for.
It just was not possible to do something like Wayland before. So I understand that it's fun for smart hackers to dig though something new, something that have never been done. But for now Wayland looks like a personal toy for its developers, that brings no benefits to anybody else.
Bad NIH, good NIH Posted Mar 10, 2013 3:07 UTC (Sun) by HelloWorld (guest, #56129) [Link]
People have explained dozens of times by now what's wrong with X11 and why it's worth working on a replacement. If you still didn't understand, it's because you don't want to, and I won't waste my time trying to convince you otherwise. Fortunately, the world keeps moving despite stick-in-the-muds like you.
Bad NIH, good NIH Posted Mar 10, 2013 15:37 UTC (Sun) by hummassa (subscriber, #307) [Link]
> People have explained dozens of times by now what's wrong with X11 and why it's worth working on a replacement.
No. No one has explained what is wrong with X11 or with its implementations.
More specifically, no one has explained why any possible flaws are not fixable.
About the worth of working on a replacement, to each its own, and no one can force others to work (or to pay someone to work) on something.
Bad NIH, good NIH Posted Mar 10, 2013 18:25 UTC (Sun) by patrick_g (subscriber, #44470) [Link]
> No. No one has explained what is wrong with X11 or with its implementations.
Please look at this video : http://www.youtube.com/watch?v=RIctzAQOe44
Bad NIH, good NIH Posted Mar 11, 2013 4:58 UTC (Mon) by Serge (guest, #84957) [Link]
>> No. No one has explained what is wrong with X11 or with its implementations.
> Please look at this video : http://www.youtube.com/watch?v=RIctzAQOe44
Presentation that starts with "Noone has any idea". Saying things like "I'm the smart guy and everybody else is stupid", even if you're joking or have reasons for that, still looks... not very polite. But let's get back to the X11 talks.
There goes an interesting story of XFree86/Xorg evolution, how it looked 20 years ago and how few features it had back then, and how many features it has now, how it adopted all the modern hardware, how older extensions were replaced by their newer versions etc.
But where are the problems? Gedit startup is too slow? Then fix gedit! The rest is like "X is doing that bad, so Wayland can't do that at all" or "X does it that way, we don't like that, so Wayland does it this way" or usually it's like "Wayland is going to do it better" because it's not implemented yet or the implementation is very basic/buggy. That's all! No problems of X11 protocol or even Xorg there.
What have I missed?
BTW, it was kind of fun listening to "X isn't network-transparent any more" while running some GUI tools over ssh -Y.
Bad NIH, good NIH Posted Mar 11, 2013 9:30 UTC (Mon) by gioele (subscriber, #61675) [Link]
> BTW, it was kind of fun listening to "X isn't network-transparent any more" while running some GUI tools over ssh -Y.
The presenter explicitly said that "X is network-capable, not network-transparent". It means that you can run X applications over the network, but the software has to handle it as a special case now, given that the current normality is the use of shared memory buffers.
Bad NIH, good NIH Posted Mar 11, 2013 4:33 UTC (Mon) by Serge (guest, #84957) [Link]
> People have explained dozens of times by now what's wrong with X11 and why it's worth working on a replacement.
No! People have dozens of times explained why they CAN work on a replacement, not why it's worth working on it. Usually all those explanations boil down to "X11 has too many features" and "Wayland is not too bad". But nobody have ever explained who's going to win from it. I would be glad if you provide me a link to such explanation.
Wayland/Weston is like a HelloWorld-program. It's useless but IN THEORY you can extend it to do whatever you want... Hm... HelloWorld is the best graphical manager! It's fast and simple! You can do everything else client-side! Sounds familiar? :-)
Bad NIH, good NIH Posted Mar 10, 2013 10:44 UTC (Sun) by nix (subscriber, #2304) [Link] Nobody needs or wants X servers for Windows, Mac OS or Android. What people want is remote applications, and they'll get those with Wayland via a VNC-like protocol. Which, by the way, works way better than X for today's applicationsThat's just as wrong as it was last time you said it. Even the Wayland developers say that to accelerate things like scrolling screenfuls of text (a common case) will require toolkit-level remoting that is aware of things like glyphs rather than just considering the framebuffer to be a big image.
Bad NIH, good NIH Posted Mar 11, 2013 12:27 UTC (Mon) by dgm (subscriber, #49227) [Link]
There are many things that can run smoother over the network if done more cleverly than just copying frames around, but:
1. Most people do not need to work over the network, specially those that have the greatest need for performance: games, video playback and such. 2. Copying frames is by far the simplest solution. 3. Being able to copy frames doesn't mean you cannot _add_ a cleverer solution.
So, a local only display covers maybe 95% of user needs, and with dumb frame copying you may be getting that up to 99% (statistics right out of my hat, but still). The remaining 1% _can_ be worked out, or just keep using X11.
The alternative is forcing network "transparency" down everybody's throat, even if they do not want or need it.
It's not really that nobody needs X11. I do, for instance. But I'm not so stupid to not realize that most people don't. And forcing them to play a price for something I need doesn't sound like a great idea.
Bad NIH, good NIH Posted Mar 11, 2013 15:27 UTC (Mon) by nix (subscriber, #2304) [Link]
I find it hard to believe that you think that playing video rendered over the network (without using something like Youtube) is a more common case than rendering scrolling text buffers over the network. The latter is about 99% of what people use X remotely *for*.
Bad NIH, good NIH Posted Mar 12, 2013 12:21 UTC (Tue) by dgm (subscriber, #49227) [Link]
> rendering scrolling text buffers over the network [...] is about 99% of what people use X remotely *for*.
Probably, but what percentage of people do use X remotely, actually?
Does it make sense to design the solution around that use case? Or would it be better to design things around the *common* use case (computing and display on the same node), specially when alternative solutions do exist?
Bad NIH, good NIH Posted Mar 13, 2013 21:41 UTC (Wed) by nix (subscriber, #2304) [Link]
I can't tell you how common it is, or isn't. I don't see how you could claim that you know that non-remote use is so common that the remote case should be disregarded, either.
Bad NIH, good NIH Posted Mar 13, 2013 20:14 UTC (Wed) by HelloWorld (guest, #56129) [Link]
> That's just as wrong as it was last time you said it.
Well, it's more or less what Daniel Stone said in his recent talk about X and Wayland.
> Even the Wayland developers say that to accelerate things like scrolling screenfuls of text (a common case) will require toolkit-level remoting that is aware of things like glyphs rather than just considering the framebuffer to be a big image.
Bad NIH, good NIH Posted Mar 13, 2013 21:46 UTC (Wed) by nix (subscriber, #2304) [Link]
So... your 'argument' is that VNC-like stuff is 'good enough', even though it is clearly much worse than glyph-by-glyph stuff for the vast majority of windows that anyone ever opens using any windowing system -- those windows filled with text? (Discounting, for these purposes, games and video playback, which clearly should be local or use a video compression algorithm of some sort.)
Almost every use case (save only the GIMP, Inkscape and their ilk) can be covered by video compression or glyph-by-glyph stuff. VNC is bad for *both* of these. As far as I can tell, VNC is far suboptimal for *everything*.
Bad NIH, good NIH Posted Mar 13, 2013 22:51 UTC (Wed) by HelloWorld (guest, #56129) [Link]
Of course it's suboptimal. It's also easy to implement and doesn't need application or toolkit changes and still works better than X (which is unusable over high-latency links). Again, the question isn't whether it's possible to do better but whether someone can be bothered to invest a significant amount of work in a better solution. Given that remote applications == web applications for 95% of all users, I don't think anybody will.
Bad NIH, good NIH Posted Mar 13, 2013 23:43 UTC (Wed) by nix (subscriber, #2304) [Link]
It doesn't work better than X over even low-latency links the moment you have to scroll. Scrolling a windowful of text using normal VNC is laggy even over a quiet gigabit ethernet link: over anything slower it is hopeless.
Bad NIH, good NIH Posted Mar 14, 2013 3:10 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
you are so focused on what is the 'norm' today that you are completely blind to the future.
remote display uses that are going to become very common in the near future (especially when connected to mobile devices that do not have the CPU power to render locally, then ship VNC style full-frame images out to the remote display)
1. Google Glasses style head mounted displays.
Google is far from the only company working on this sort of thing. Many of these uses are text or simple geometric objects overlayed on the live video, shipping the video to the phone, doing the overlay, and shipping the result back out is wasting a lot of bandwidth, and battery. Not Going To Happen (at least not for very long). What's going to happen is the video will get shipped to the phone (although not necessarily in full resolution), the phone will craft the overlay, and the overlay will be transmitted back to the headpiece to be combined there with the direct feed from the camera.
2. remote displays (frequently wireless) from mobile devices to large, high-res displays.
Haven't you seen any of the many TV shows or movies recently that show people pulling something up on a phone/tablet and then 'flicking' the window over to the full display? What makes you so sure that this is not going to happen?
There are probably a lot of other examples that people could point out, but just because you don't currently use remote displays doesn't mean that they aren't going to be very popular very soon.
Bad NIH, good NIH Posted Mar 8, 2013 23:58 UTC (Fri) by Serge (guest, #84957) [Link]
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?
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.
|
|||||||||||||
