X.Org Could Use More Help Improving & Addressing Its Security

[pal666]

while in Wayland whole window is application managed area and your application will get input event, not some DE/WM system event.

so, in wayland your windows react to clicks on window buttons and elsewhere as needed or not?

[pal666]

A proper multi-head support

i'm pretty sure wayland has better multi-head support than x11

[oiaohm]

The article you linked to tells a different story to me, unlike your interpretation. What FreeType v40 bypassing is patented subpixel hinting (grid-fitting). FreeType still need to know the monitor orientation to apply subpixel AA and hinting to their corresponding direction. In standard subpixel order, left edge pixel is blueish and right edge pixel is redish. When a monitor is flipped upside down, the left edge pixel now shall be redish and right edge pixel shall be blueish. In standard orientation hinting is only done vertically while a 90 degree rotated screen will do hinting horizontally.

freetype uses grey scale /flat color AA by default and did not have subpixel AA for a very long time. So none of the redish/blueish stuff that requires a multi colour AA/subpixel usage for this problem.
http://wp.xin.at/archives/4702 yes the greyscale AA is noted here.
Yes people have attempted bring greyscale AA to windows because you avoid this redish/blueish issue by not using multi color AA in the first place.

“Greyscale font Anti-aliasing” is something that is different to windows. Greyscale font Anti-aliasing come out of patent avoidance by freetype but then resulted in bugger me moment this is just as good on screen as the patented options with none of the draw backs for fonts once you cross a particular DPI level. Using greyscale font anti-aliasing you don't need to know the corresponding direction of the monitor because this form of AA does not need to know "subpixel color order" because all colours in a pixel are being adjusted unified(yes simpler processing as well). Windows standard font AA does process all the colour channel individually this does require you to know monitor orientation.

Yes the general Linux font AA is greyscale AA not multi color AA/subpixel AA.

https://forums.macrumors.com/threads/the-subpixel-aa-debacle-and-font-rendering.2184484/post-28912005

Yes apple default is greyscale AA, Android default is greyscale AA. Yes that apple compare there where the person thinking the difference is subpixel 95% of the difference is not subpixel but gamma valve.

https://forums.macrumors.com/threads/the-subpixel-aa-debacle-and-font-rendering.2184484/page-10?post=29429586#post-29429586

Turns out greyscale AA can be very good on modern screens with modern DPI levels .

Yes greyscale AA there is not using subpixel hinting in the second link either. Greyscale AA + modern font rendering methods does a really good job without using the subpixel stuff.

Linux out the box distributions reality don't have subpixel AA turned on in freetype. So the majority of your Linux applications don't need to know monitor orientation. If you are going to be software up-scaling the application output window again you most likely want the application to use Greyscale AA. Then if required apply subpixel AA after the output has been up-scaled.

billyswong greyscale AA on fonts is a lot more common than people would think. Yes as the DPI goes up and the methods todo greyscale AA font stuff with good hinting the reasons for subpixel font hinting and AA going away. Yes with HiDPI screens being able to not tell application screen orientation comes important so application can be upscaled well because it does not subpixel render because that information is missing.

No objection to the need of lying for legacy software. We are going to convert legacy software from SDR bitmap to HDR bitmap in compositor side for HDR monitors already.

With X11 there is a need because the applications will request detailed monitor information that will include information that causes them todo something stupid.

(A) subpixel color order / orientation and (B) the "DPI" or more accurately the intended scaling factor.

The point A here does not apply to fonts on Linux that much due to how much grey-scale AA is used. Game AA or some graphical software AA maybe but not font AA for the majority because of the common default freetype AA being greyscale AA.

B being DPI not so much. Scaling factor I would say is important. Think the case a person with poor version DPI of the monitor may not be the DPI you want the application to know. You may want a application to think its on hiDPI monitor when it really on a standard DPI monitor so it shown over scale to user without really scaling it.

Really you want the application to believe the screen/monitor DPI is what ever the user wish the application to believe it is. So fake not the real monitor DPI unless the user wants the application to know the real monitor dpi. This requires a different method to collect data from hardware and just give it to the application as X11 uses.

[billyswong]

i'm pretty sure wayland has better multi-head support than x11

I was giving very specific cases. One of them is "subpixel AA and font hinting for text". Can Wayland apply them correctly in mixed DPI environment now? No, we cannot. X11 is old and it is reasonable for it to have zero support of mixed DPI. Wayland should have designed to support this specific case in day 1. But no, we still can't do it. Worse, most Wayland maintainers and fanboys refuse to admit it is a problem.

[billyswong]

oiaohm Some people like no AA. Some people like grayscale AA. Some people like subpixel AA. These are personal preference. I am currently using subpixel AA in my home Linux box. For Android there is a very strong reason not using subpixel AA - the screen rotate too often and they don't want to cache 4 different bitmaps for each glyph. Apple don't use subpixel AA probably because "artists" are more sensitive to color fringe.

No matter which kind of AA or no AA one prefer, hinting / grid-fitting is still essential for "96dpi" screens, no matter they are physically really 96dpi or not. My point still hold: there is no mechanism in Wayland yet, for a software to output its window surface a low dpi bitmap frame to low dpi monitor and a high dpi bitmap frame to high dpi monitor at the same time. So a Wayland application when placed overlapping both screens, is suboptimal in output quality.

[pal666]

X11 is old and it is reasonable for it to have zero support of mixed DPI

so we agree that wayland has better multi-head support than x11?

[birdie]

I was giving very specific cases. One of them is "subpixel AA and font hinting for text". Can Wayland apply them correctly in mixed DPI environment now? No, we cannot. X11 is old and it is reasonable for it to have zero support of mixed DPI. Wayland should have designed to support this specific case in day 1. But no, we still can't do it. Worse, most Wayland maintainers and fanboys refuse to admit it is a problem.

What you're hinting at requires a graphical toolkit which works closely with the graphical system and we have none. Every other successful OS out there has a toolkit closely coupled with its window system/GUI which Linux adepts don't accept. Actually Xorg has a low level graphical toolkit because X11 provided one but Wayland threw that idea away.

[blacknova]

so we agree that wayland has better multi-head support than x11?

There is literally nothing about monitors configuration in Wayland's protocol documentation. So the way it is implementing is completely up to compositor.
And that is all. Applications have zero configuration introspection, they can query nothing about monitors from compositor through standard protocol (as there no protocol defined).

Update.
Ok, just rechecked. wl_output is that I've been looking for and it should be able to provided information alike xrandr.
So far both X11 and Wayland work with unified monitors workspace, both can provide the same information to application.
So I'm not sure if one of them is better than another.

[mdedetrich]

your biggest mistake is to discuss stuff in which you have zero understanding

Right back at you pal (pun intended) as is evidenced by your latest comments.

[billyswong]

What you're hinting at requires a graphical toolkit which works closely with the graphical system and we have none. Every other successful OS out there has a toolkit closely coupled with its window system/GUI which Linux adepts don't accept. Actually Xorg has a low level graphical toolkit because X11 provided one but Wayland threw that idea away.

My proposal is letting a software "output its window surface a low dpi bitmap frame to low dpi monitor and a high dpi bitmap frame to high dpi monitor at the same time". Wayland don't need to provide a graphical toolkit. As long as hardware acceleration like OpengGL, Vulkan and video decoding can be applied to client surface before composition, it is good enough in this aspect. Because of DLSS / FSR, 3D applications may not be drawing in native dpi in the first place anyway. What's important is to allow applications to do the scaling / tonemapping themselves for mixed monitors.