Bug 430182 - Thickness of URL underlines is not rounded to be pixel-aligned when using fractional scaling
Summary: Thickness of URL underlines is not rounded to be pixel-aligned when using fra...
Status: CONFIRMED
Alias: None
Product: konsole
Classification: Applications
Component: general (show other bugs)
Version: 20.08.3
Platform: Debian testing Linux
: NOR minor
Target Milestone: ---
Assignee: Konsole Developer
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-12-09 12:05 UTC by 1107309266
Modified: 2020-12-29 00:47 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
screenshots (520.00 KB, application/gzip)
2020-12-09 12:05 UTC, 1107309266
Details

Note You need to log in before you can comment on or make changes to this bug.
Description 1107309266 2020-12-09 12:05:28 UTC
Created attachment 133947 [details]
screenshots

KDE Plasma Version: 5.19.5
KDE Frameworks Version: 5.74.0
Qt Version: 5.15.1
Scaling: 125% on a 1080p display

When I move the mouse pointer to the url, it will show an underline below the url, but I found that the underlines are different.

I uploaded two screenshots, you can see two underlines in these screenshots, one is thick, another is thin.

Could this have something to do with this bug?
https://bugs.kde.org/show_bug.cgi?id=373232
Comment 1 Nate Graham 2020-12-09 16:17:21 UTC
This is a scaling artifact. By using a 125% scale factor, you told Konsole to make everything 125% bigger, but the physical pixels in your screen didn't become 125% bigger. As a result, everything that was previously pixel-aligned--like the underline--can no longer be pixel-aligned.

If we rounded the line's thickness to always be pixel-aligned, then when using a 125% scale factor, it would be rounded down and appear thinner than originally intended, but it would be pixel-aligned again. When using a 175% scale factor, it would be rounded up and appear thicker than originally intended. When using a 150% scale factor... what would it do? Become substantially thinner or thicker than expected? Which one? I guess we would have to choose one.

An argument can be made that rounding to be thicker or thinner than intended may be better than letting the system do what it's currently doing and varying based on pixel positioning.

Perhaps we can look into it.