>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.
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?
Correct.
>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.
Subpixel rendering allows to draw better looking curves by taking into account the fact that physical pixels on the screen consist of discrete subpixels.
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.
Wayland exposes the surface orientation to applications (surprise!), while X doesn't. So applications can adapt their rendering settings if they can.
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.
Lessee:
>cyberax@whale2:~$ xrandr --verbose
> SZ: Pixels Physical Refresh
>*0 1024 x 768 ( 260mm x 195mm ) *60
>Current rotation - normal
>Current reflection - none
>Rotations possible - normal
>Reflections possible - none
>Setting size to 0, rotation to normal
>Setting reflection on neither axis
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.