https://bugs.kde.org/show_bug.cgi?id=465433
--- Comment #8 from zvova7...@gmail.com --- >> Just to confirm the middle one we're saying is fine? Yes, right. It is better to download the image and view it in gwenview, for example. The left one is more "hairy", visible effect of scaling. I tested Qt 6.5 on Arch Linux some time ago, and although I don't recall the exact details, I do remember that the rendering was fine. I believe I made adjustments to these environment variables during my testing: #QT_AUTO_SCREEN_SCALE_FACTOR=1 #QT_SCALE_FACTOR_ROUNDING_POLICY=PassThrough So, cross the fingers for the plasma 6 :) Also, invalid qscreen scaling can broke some apps, that rely on it. For example, some apps can get scaling settings when the window has been not yet created and pass it to some part of code that can't dynamically change the scaling factor. I hope we would't see that apps, but who knows. As example I can provide some android emulators, based on containers, like anbox or waydroid. Anbox session starts android in background, passing scale factor to the container and doesn't have technical capabilities to change the scale when user open a window. If I understand correctly, we can't get current display fractional scale factor until we doesn't have a window with attached scale factor protocol. It is not only qt-related, it's true for all wayland apps. Do we currently have the capability or are there any existing plans to get a selected display scale factor with floating-point accuracy? -- You are receiving this mail because: You are watching all bug changes.
