Bug 425190 - Fractional Qt scaling makes monochrome line-art icons look blurrier than necessary
Summary: Fractional Qt scaling makes monochrome line-art icons look blurrier than nece...
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: general (show other bugs)
Version: unspecified
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-08-10 14:49 UTC by Claudius Ellsel
Modified: 2023-12-08 12:13 UTC (History)
6 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
Source used for scaling attempts (113.26 KB, image/png)
2020-08-10 14:49 UTC, Claudius Ellsel
Details
No algorithm for scaling selected (258.06 KB, image/png)
2020-08-10 14:49 UTC, Claudius Ellsel
Details
Linear algorithm (258.06 KB, image/png)
2020-08-10 14:50 UTC, Claudius Ellsel
Details
Cubic algorithm (258.06 KB, image/png)
2020-08-10 14:50 UTC, Claudius Ellsel
Details
NoHalo algorithm (258.06 KB, image/png)
2020-08-10 14:50 UTC, Claudius Ellsel
Details
LoHalo algorithm (258.06 KB, image/png)
2020-08-10 14:51 UTC, Claudius Ellsel
Details
Original used for downscaling (370.26 KB, image/png)
2020-08-11 16:12 UTC, Claudius Ellsel
Details
Downscaling with linear algorithm (137.25 KB, image/png)
2020-08-11 16:12 UTC, Claudius Ellsel
Details
Downscaling with NoHalo algorithm (137.23 KB, image/png)
2020-08-11 16:13 UTC, Claudius Ellsel
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Claudius Ellsel 2020-08-10 14:49:18 UTC
Created attachment 130754 [details]
Source used for scaling attempts

SUMMARY
There currently is the inherent issue of having blurred results when using fractional scaling. However, there are better and worse algorithms for that. Also one might think about completely moving away from simply scaling things up and use pixel perfect graphics, maybe derived from svg graphics instead.

I did some short test with GIMP and different algorithms for upscaling. See the attachements. It is clearly visible that NoHalo and LoHalo reduce the blurriness in comparison to Cubic or Linear. I don't know which algorithm is currently used, but there might be potential for improvement there.

I might have filed this for the wrong product, please check, whether this is correct.
Comment 1 Claudius Ellsel 2020-08-10 14:49:54 UTC
Created attachment 130755 [details]
No algorithm for scaling selected
Comment 2 Claudius Ellsel 2020-08-10 14:50:11 UTC
Created attachment 130756 [details]
Linear algorithm
Comment 3 Claudius Ellsel 2020-08-10 14:50:28 UTC
Created attachment 130757 [details]
Cubic algorithm
Comment 4 Claudius Ellsel 2020-08-10 14:50:46 UTC
Created attachment 130758 [details]
NoHalo algorithm
Comment 5 Claudius Ellsel 2020-08-10 14:51:07 UTC
Created attachment 130759 [details]
LoHalo algorithm
Comment 7 Nate Graham 2020-08-10 15:42:56 UTC
This might be done at the Qt level, in fact. But I'll let the KWin developers give you the truth since that's just speculation. :)
Comment 8 Christoph Feck 2020-08-10 17:40:49 UTC
Is this with Wayland? KWin on X11 doesn't scale.
Comment 9 David Edmundson 2020-08-10 17:58:11 UTC
There is no upscaling. If there is you've got a different bug. Please check
Comment 10 Claudius Ellsel 2020-08-10 18:19:33 UTC
(In reply to Christoph Feck from comment #8)
> Is this with Wayland? KWin on X11 doesn't scale.

Yes this is on Wayland. As I said, this is about fractional scaling set in the view settings. KWin might be the wrong product to file this.

(In reply to David Edmundson from comment #9)
> There is no upscaling. If there is you've got a different bug. Please check

So when applying fractional scaling, say a factor of 1.25 the icons, mouse cursor etc. are not upscaled?
Comment 11 Roman Gilg 2020-08-10 18:42:02 UTC
(In reply to Claudius Ellsel from comment #10)
> So when applying fractional scaling, say a factor of 1.25 the icons, mouse
> cursor etc. are not upscaled?

They are rendered at 2-times the normal size and then downscaled. That's the theory, in practice there can always be issues.

I believe sometimes Qt Wayland clients do not update their size when changing the scale factor. And then there is of course Xwayland.
Comment 12 Claudius Ellsel 2020-08-10 18:47:36 UTC
(In reply to Roman Gilg from comment #11)
> (In reply to Claudius Ellsel from comment #10)
> > So when applying fractional scaling, say a factor of 1.25 the icons, mouse
> > cursor etc. are not upscaled?
> 
> They are rendered at 2-times the normal size and then downscaled. That's the
> theory, in practice there can always be issues.

Do you mean upscaled? A factor of 1.25 increases the size of the icons. This was my whole question, as David Edmundson stated there wouldn't be upscaling.

> I believe sometimes Qt Wayland clients do not update their size when
> changing the scale factor. And then there is of course Xwayland.

The size is updated properly, only they are blurred. This is what this issue is about.
Comment 13 David Edmundson 2020-08-10 21:16:47 UTC
I said the specific thing in your screenshot shouldn't be upscaled. 
If fractional scaling was applied that could result in a downscale of the original client texture.
Comment 14 Nate Graham 2020-08-10 22:25:08 UTC
David, I think Claudius is using the term "scaling" as a user understands the term, not as a KWin developer understands the term. Looking at the attachments, clearly there are differences in the different ways that images can be scaled up. Knowing that fractional scaling downscales from a doubled pixel-perfect version, it might be interesting to repeat the tests with downscaled images.
Comment 15 Claudius Ellsel 2020-08-11 01:10:12 UTC
(In reply to Nate Graham from comment #14)
> David, I think Claudius is using the term "scaling" as a user understands
> the term, not as a KWin developer understands the term. Looking at the
> attachments, clearly there are differences in the different ways that images
> can be scaled up. Knowing that fractional scaling downscales from a doubled
> pixel-perfect version, it might be interesting to repeat the tests with
> downscaled images.

Ah, I see my mistake now. Roman Gilg already pointed that out, but I did not understand it then.

I just assumed it would be scaled up. Downscaling obviously is the better approach to implementation, since no information has to be interpolated, so that makes sense.

This renders the different algorithm comparisons I posted rather pointless. However, I read the the NoHalo algorithms were actually developed for downscaling in particular and that blurriness can also happen when scaling down. So the general idea that there might be better algorithms still seems to be valid.
Comment 16 Claudius Ellsel 2020-08-11 16:11:56 UTC
Alright, I have done some testing with the downscaling from a 2x version (took a screenshot on X11 with that scale factor, had to manually double the size of the panel, too). Did not work to take that screenshot on Wayland due to https://bugs.kde.org/show_bug.cgi?id=425226.

I tested Linear against NoHalo scaling the version down by a factor of roughly 0.6 and there is almost no noticeable difference. So it seems that downscaling works good in this use case pretty much regardless of which algorithm is used.

The reason why I opened this was https://bugs.kde.org/show_bug.cgi?id=408215. This might have a different root cause, though.

Also there is a noticeable blurred notification tray icon in the panel on Wayland with fractional scaling applied. This might also be related to some different root cause, though. Unfortunately, due to https://bugs.kde.org/show_bug.cgi?id=425226 I cannot create a screenshot depicting the problem.
Comment 17 Claudius Ellsel 2020-08-11 16:12:18 UTC
Created attachment 130785 [details]
Original used for downscaling
Comment 18 Claudius Ellsel 2020-08-11 16:12:39 UTC
Created attachment 130786 [details]
Downscaling with linear algorithm
Comment 19 Claudius Ellsel 2020-08-11 16:13:02 UTC
Created attachment 130787 [details]
Downscaling with NoHalo algorithm
Comment 20 Roman Gilg 2020-08-11 17:31:32 UTC
Interesting comparison. Linear looks to me even better. Might there be other algorithms improving upon that though?
Comment 21 Claudius Ellsel 2020-08-11 18:43:12 UTC
(In reply to Roman Gilg from comment #20)
> Interesting comparison. Linear looks to me even better. Might there be other
> algorithms improving upon that though?

Yes, there might. Although from what I read NoHalo in GIMP already seems to do a pretty decent job for most cases (https://www.gimpusers.com/system/tutorial_steps/3061/sampling-original.jpg), although that might not cover the special use case of KDE.

There seems to have also been a LoBlur algorithm be planned for GIMP (https://www.gimpusers.com/tutorials/whats-new-in-gimp-2-10 point 4) in 2012, which is not available today. Since GIMP is probably only using known approaches, there might be already at least theoretical algorithms out there for this use case.

Also another reference for the NoHalo algorithm in GIMP: http://libregraphicsworld.org/blog/entry/advanced-samplers-for-gegl-to-be-crowdfunded
Comment 22 Bug Janitor Service 2020-08-26 04:33:09 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!
Comment 23 Claudius Ellsel 2020-08-26 13:34:46 UTC
Setting back to "reported" as I think I provided all required information. Did not know that I am supposed to change the state myself and did not want to come off rude by changing it.
Comment 24 Carlos 2021-01-14 19:47:03 UTC
> Linear looks to me even better.

I believe both Mutter and Sway use linear but fallback to nearest for the special case of integer scaling (see [1] and [2]). xrandr uses bicubic (although that can be changed to nearest [3]). I haven't done a side-by-side comparison, but I find all of them work rather fine compared to how tray icons scale in Plasma panel. We are probably seeing upscaling there and I suppose there are no handcrafted 2x icons to downscale from.

Cludius: I don't understand your second experiment quite well. When you upscaled x2 you just took the small icons and duplicated everything? If that's the case, it might be worth for comparative purposes but I don't think as a scaling technique that would improve too much on plain upscaling, since it's not adding any new information (like, say, a handcrafted version or an upscaled svg version).

---

[1] https://github.com/swaywm/wlroots/issues/1770
[2] https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/845
[3] https://www.reddit.com/r/GPDPocket/comments/90bras/tip_nearestneighbor_xrandr_display_scaling/
Comment 25 Claudius Ellsel 2021-01-14 20:41:40 UTC
(In reply to Carlos from comment #24)
> Cludius: I don't understand your second experiment quite well. When you
> upscaled x2 you just took the small icons and duplicated everything? If
> that's the case, it might be worth for comparative purposes but I don't
> think as a scaling technique that would improve too much on plain upscaling,
> since it's not adding any new information (like, say, a handcrafted version
> or an upscaled svg version).

You mean my first experiment? I upscaled in the first series and for the second series I downscaled (after learning that icons are at least in theory only downscaled), both times starting with (I think) a screenshot of a desktop with 1x or 2x scale factor respectively.

The tray icons in the second approach's 2x source are just looking that small originally.

Does that help?
Comment 26 David Edmundson 2023-12-08 12:13:21 UTC
QtWayland now has native fractional sacling, we don't need to do workarounds at a kwin level