Window Outlines are Blurry on High DPI Setups

[Infinality]

On my 150% scaled setup, 1px window outlines appear blurry and thicker than 1px. What I suspect is happening is that the 1px border is being calculated on a standard 100% basis and then when the scaling is at 150%, you're actually getting 1px scaled up to 1.5 pixels. Ideally, klassy should be aware that it's running under a certain scaling (125%, 150%, 200%, etc.) so that 1px is literally rendered as 1px. Or as a workaround, outline width pixel values less than 1 should be allowed. For instance: If I were to set the value at 0.66, it would counteract the artificially inflated 1.5px value back to 1px.

It honestly doesn't look horrible the way it is currently, but it's not really doing what it's saying it is. Preferably it could somehow allow both methods- perhaps a checkbox that says, "Respect plasma scale values".

[Infinality]

[Infinality]

There seems to be a related issue with dividers and outlines in menus, tabs and windows. They appear to either snap to 1px or 2px integer values randomly however, rather than being blurry (fractional values).

[paulmcauley]

The outline thickness also includes a 0.5 pixel overlap to work around fractional scaling errors. You can't easily specify the exact thickness on Wayland - the set value is scaled by whatever the scaling is so you have to adjust manually the setting until you get an exact thickness you want. To fix properly requires a kwin/KDecoration2 API update.

For the second point, does this also happen in Breeze application style? This is most likely inherited from there.

[Infinality]

You're right: The second thing does happen with Breeze application style too. It's interesting (but not surprising) that most of these issues are actually upstream issues. I figured after ~10 years of development, the Linux people would have have high DPI down to a science, but it's still a glitchy mess. ¯_(ツ)_/¯

Does it make sense to allow values lower than 1.00 as a workaround or will that produce obviously bad results in all cases?

[paulmcauley]

To do it better, at a minimum the KDecoration2 API needs to give the decoration access to DevicePixelRatioF.

At 150% scaling it will give 1 pixel outline, with an additional 0.5 px overlap, if you set the thickness to 1.0.

PS: are you the guy behind the Freetype patches? I was thinking an alternative to writing my own pixel-snapping routines as I have done here, a lot of the icons could be specified as a font and sub-pixel snapped if some of the same techniques from Freetype were used. I am not that familiar with Freetype though.

[Infinality]

Yes, I am, but if you can believe it, even though I've done lots of coding I've never actually implemented any code that leverages freetype. And, I knew very little about it (or fonts) when I starting playing with the code and wrote those patches.

What you're suggesting sounds plausible, but the advantage of doing so may or may not be worth the extra complexity.

[Infinality]

Here's another thing I found. I'm guessing it's probably the same thing where the API needs to be updated:

This is a transparent console window with blur applied. You can see the klassy blue window border at the bottom, but if you look between the border and the dark console area, you can see an exact 1px horizontal line between them. It appears to be 100% transparent, but blurred, of whatever is underneath this window. Strangely, it doesn't happen all the time, just sometimes.

[AlexFolland]

I set my window outlines to exactly 1.00 pixel thickness and 100% opacity, but it is still partially transparent, blending with the nearby pixels. Something seems wrong with the calculation of its color and/or position.

[Infinality]

My guess is that this also is a KDecoration2 API issue like the one I reported. I'm continually surprised that we're ~ 15 years into "High DPI" technology and all of these codebases & APIs are riddled with problems. ¯\(ツ)/¯

[paulmcauley]

I set my window outlines to exactly 1.00 pixel thickness and 100% opacity, but it is still partially transparent, blending with the nearby pixels. Something seems wrong with the calculation of its color and/or position.

A 0.5 pixel overlap is added to account for fractional scaling errors. If you are at 100% scaling then set to 1.5 for a sharp 1px outline

[AlexFolland]

OK, I tested that and it is indeed true. When set to 1.50, the window outline is correctly 1.00 pixel thick. That sounds like it is the cause of this reported issue, at least for me. The compensation for a potential issue seems to have introduced an actual issue, where the configured value doesn't match the value that's used, leading to needing a workaround. Can we expect the compensation to be removed or hidden internally, to fix this reported issue?