| |||||||||||||
Bad NIH, good NIHBad NIH, good NIHPosted Mar 11, 2013 6:35 UTC (Mon) by Cyberax (✭ supporter ✭, #52523)In reply to: Bad NIH, good NIH by Serge Parent article: Canonical reveals plans to launch Mir display server (The H)
> 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).
(Log in to post comments)
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.
|
|||||||||||||