unity picks poor hidpi scale factor defaults

Bug #1649736 reported by David Jordan on 2016-12-14
18
This bug affects 1 person
Affects Status Importance Assigned to Milestone
unity (Ubuntu)
Undecided
Unassigned
Nominated for Xenial by Marco Trevisan (Treviño)
Xenial
Undecided
Unassigned

Bug Description

[Impact]
The recently set-hidpi-scale-factor branch provides extremely valuable support for hidpi displays, but it does introduce a few easily fixed regressions because of the way it anchors scaling too rigidly to simulate 140 DPI.

This works well on a 15" Full HD or 4K screen, but sets a non-integer scale factor on 14" and 17" Full HD or 4K screens. Most toolkits don't support non-integer scaling factors very well, and even if they did, it would still result in a loss of sharpness.

The displays mentioned above are perfectly usable at the nearest integer scaling factor, and windows render much more cleanly when set to 1x or 2x than 1.125x or 1.875x. The +-1/8 scale difference in size compared to 1x or 2x isn't worth breaking pixel perfect widget rendering. It would be a good idea to try to default to integer scaling factors whenever reasonable. Otherwise most people will have mangled widgets unless they spend the time to set the scale factor themselves.

Here's the relevant merge: https://code.launchpad.net/~kaihengfeng/unity/set-hidpi-scale-factor/+merge/299380

[Test Case]
1. Open "System Settings..."
2. Open Display Panel
3. Scale monitor to "1.75"
4. gsettings get org.gnome.desktop.interface scaling-factor
5. The above commands returns 2

[Potential Regression]
None

Related branches

Kai-Heng Feng (kaihengfeng) wrote :

Would you like to provide some idea about when it's reasonable to use integer only scaling, when it's not?

David Jordan (dmj726) wrote :

After thinking through the various cases, I think the cases where integer scaling can't provide an ideal widget size are also the cases where user's preferences are going to be split. There is also at least one usable integer scale for any given dpi.

I did a fair bit of testing to simulate the apparent scale of widgets. Everything from 140 dpi up to 210 dpi is usable at 1x. Everything between 210 dpi and 280 dpi is usable at 2x (if sometimes a bit big).

Exactly 210 dpi is usable either way, and I could see different users choosing 1x, 2x, or 1.5x depending on their preference between a) lots of screen real estate, b) big, readable text, or c) average size at the expense of broken widget rendering.

I think we can provide a usable default experience actually with just integer scaling. 140 dpi is good as the optimal target, but instead of rounding to eighths, just round to a whole integer (Scale factor or 8 or 16). The usability problems for 1x scaling begin just above 210 dpi, so above that 2x is appropriate.

That way we deliver correct widget rendering out of the box. The fractional scaling will still be there in the settings for people who prefer to optimize size and screen real estate at the cost of ugly GTK rendering.

Kai-Heng Feng (kaihengfeng) wrote :

Can you attach a screenshot of the "broken widget rendering"? Sounds like it's a separate issue and we should fix it properly.

In the meantime, I think we can add an extra knob for something like "integer-scaling", to make scale-factor always round to 8 or 16. But I doubt Unity upstream would like it though.

But we should fix broken things as well.

Changed in unity (Ubuntu):
assignee: nobody → Kai-Heng Feng (kaihengfeng)
David Jordan (dmj726) wrote :

The "broken widget rendering" is a manifestation of how GTK3 handles HiDPI. GTK3 doesn't natively scale at 1/8 increments, so Unity's scaling is working around that by messing with the size of text and widgets.

To give you an idea, I'm attaching a screenshot of the same window as rendered at 1x (as on a 140dpi screen) and 1.5x (as on a 210dpi screen). You can see how the text nearly overflows the switches and drop downs. Plus the window doesn't resize correctly (same width in pixels but physically smaller).

To actually get non-integer scaling to look right would be quite a big effort. We'd need to either patch the major toolkits to support non-integer scaling or modify Ubuntu's window manager/compositor to render individual windows at the next integer scale up (2x) and then rescale the window down to the correct size (1.5x), plus add proper input redirection support in X.

That's why I'm suggesting we minimize the number of people we give non-integer scaling.

Kai-Heng Feng (kaihengfeng) wrote :

Thanks for your useful feedback!

So we can either
1. Add an extra knob to choose integer scaling, default to true, or
2. Just use integer scaling altogether.

I subscribed upstream maintainer to see which one is preferable.

David Jordan (dmj726) wrote :

This patch should scale to the nearest integer scaling factor.

The attachment "hidpi-integer-scaling.patch" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

tags: added: patch
Kai-Heng Feng (kaihengfeng) wrote :

David, can you try [1]?

I just tried it, the patch works great on my 4k monitor.

[1] https://code.launchpad.net/~azzar1/unity/round-gtk-scaling-to-closest-integer/+merge/313459

Changed in unity (Ubuntu):
assignee: Kai-Heng Feng (kaihengfeng) → nobody
David Jordan (dmj726) wrote :

I just tried the merge proposal, and it works much less great for me. The merge proposal changes don't improve the default scaling, which is the focus of this bug, but it does make it very difficult for users to choose an in-between scale if they want or need it for accessibility reasons.

Kai-Heng Feng, What's the physical size of your 4K monitor, and what scaling size does this pick for you?

Kai-Heng Feng (kaihengfeng) wrote :

No it didn't change how it pick the default scaling, it only scales widgets to make what you described in comment #4 works better.

As you mentioned, GTK+3 does not support 1/8 increments, so if we just want everything in widgets to scale proportionally to the 1x scale, we should use integer scaling only.

Andrea Azzarone (azzar1) wrote :

At this point I think we need both patches. My patch is useful because I don't see any reason to have unity scaling to 1.99 and gtk scaling to 1.

Andrea Azzarone (azzar1) on 2016-12-20
Changed in unity (Ubuntu):
status: New → In Progress
David Jordan (dmj726) wrote :

Yes, I had a momentary brain glitch. 1.5x is a better place to put the sudden jump in size than 2x, so yes, your patch is a good improvement, and with both patches I think we'll have a good solution.

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package unity - 7.5.0+17.04.20170109-0ubuntu1

---------------
unity (7.5.0+17.04.20170109-0ubuntu1) zesty; urgency=medium

  [ Andrea Azzarone ]
  * Round gtk scaling factor to closest integer. (LP: #1649736)
  * Keep the screen locked if rebooting with autologin. (LP: #1600389)

  [ Eleni Maria Stea ]
  * shouldn't create blur rectangles when there's no blur, skips the
    blur rects processing in low gfx.

 -- Marco Trevisan (Treviño) <mail@3v1n0.net> Mon, 09 Jan 2017 15:10:02 +0000

Changed in unity (Ubuntu):
status: In Progress → Fix Released
Kai Mast (kai-mast) wrote :

So this patch totally broke my desktop. 1x is way too small 2x is absurdly huge. 1.5x would be perfect (and was in xenial...)

Any idea how I can fix this for my setup (Thinkpad T460s with a 4k screen)?

Andrea Azzarone (azzar1) on 2017-07-17
description: updated

Hello David, or anyone else affected,

Accepted unity into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/unity/7.4.5+16.04.20171116 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-xenial to verification-done-xenial. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-xenial. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in unity (Ubuntu Xenial):
status: New → Fix Committed
tags: added: verification-needed verification-needed-xenial
Łukasz Zemczak (sil2100) wrote :

Hello David, or anyone else affected,

Accepted unity into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/unity/7.4.5+16.04.20171201.3 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-xenial to verification-done-xenial. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-xenial. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers