https://bugs.kde.org/show_bug.cgi?id=412447
--- Comment #15 from Nate Graham ---
Git commit 2b23256b0a47526715e98352fe3a12db520c306f by Nate Graham.
Committed on 16/10/2019 at 14:50.
Pushed by ngraham into branch 'master'.
[KCM] Limit scale factor increment to 6.25% on X11
Summary:
Because of t
https://bugs.kde.org/show_bug.cgi?id=412447
--- Comment #14 from Nate Graham ---
(In reply to Christoph Cullmann from comment #10)
> Btw., to see the concrete benefit, try out the following:
>
> export QT_SCALE_FACTOR=1.1
>
> use current master version of frameworks + kwrite, open a file, selec
https://bugs.kde.org/show_bug.cgi?id=412447
--- Comment #13 from Christoph Cullmann ---
Btw., if you want to read up why such 0.1 or 0.05 things create issues for
computation, take e.g. a look at
https://docs.python.org/3/tutorial/floatingpoint.html
Actually a good explanation why you get very s
https://bugs.kde.org/show_bug.cgi?id=412447
--- Comment #12 from Christoph Cullmann ---
This would be the output code change:
// round to the nearest 1/16 multiple
const double minimalScaleStep = (1. / 16.);
info[QStringLiteral("scale")] = qRound(output->scale() / minimalScaleStep) *
minimalScal
https://bugs.kde.org/show_bug.cgi?id=412447
--- Comment #11 from Christoph Cullmann ---
> Would it work if we internally round it before storing? E.g. f = qRound(f *
> 32) / 32. For displaying, it would use f = qRound(f * 20) / 20. Some testing
> would be needed to confirm this mapping is bijec
https://bugs.kde.org/show_bug.cgi?id=412447
--- Comment #10 from Christoph Cullmann ---
Btw., to see the concrete benefit, try out the following:
export QT_SCALE_FACTOR=1.1
use current master version of frameworks + kwrite, open a file, select many
lines and then scale the font up and down
In
https://bugs.kde.org/show_bug.cgi?id=412447
--- Comment #9 from Christoph Feck ---
Would it work if we internally round it before storing? E.g. f = qRound(f * 32)
/ 32. For displaying, it would use f = qRound(f * 20) / 20. Some testing would
be needed to confirm this mapping is bijective, otherwi
https://bugs.kde.org/show_bug.cgi?id=412447
--- Comment #8 from Christoph Cullmann ---
Thanks already for this nice improvement.
I still think that some minimal factor of 0.0625 would be preferable, this
would make the rounding on output unnecessary, too.
--
You are receiving this mail because
https://bugs.kde.org/show_bug.cgi?id=412447
Nate Graham changed:
What|Removed |Added
Resolution|--- |FIXED
Latest Commit|
https://bugs.kde.org/show_bug.cgi?id=412447
--- Comment #6 from Nate Graham ---
https://phabricator.kde.org/D24321
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=412447
Nate Graham changed:
What|Removed |Added
Assignee|kscreen-bugs-n...@kde.org |n...@kde.org
Status|CONFIRMED
https://bugs.kde.org/show_bug.cgi?id=412447
--- Comment #5 from Christoph Cullmann ---
The main issue is:
0.1 is no floating point value you can represent on a machine.
With factors like 1.1, you get rounding artifacts everywhere.
Even if you scale something trivial like a 10 pixel UI element w
https://bugs.kde.org/show_bug.cgi?id=412447
Christoph Feck changed:
What|Removed |Added
CC||cf...@kde.org
--- Comment #4 from Christoph Fe
https://bugs.kde.org/show_bug.cgi?id=412447
--- Comment #3 from Dominik Haumann ---
I think Christoph's point is exactly about NOT allowing these 0.1 increments.
Say we optimize it in such a way that we have the 2^-n steps (e.g. 0.125, or
0.25), then these values at least can be represented as fl
https://bugs.kde.org/show_bug.cgi?id=412447
Christoph Cullmann changed:
What|Removed |Added
CC||cullm...@kde.org
--- Comment #2 from Chris
https://bugs.kde.org/show_bug.cgi?id=412447
Nate Graham changed:
What|Removed |Added
CC||n...@kde.org
Status|REPORTED
16 matches
Mail list logo
