D24321: [KCM] Scale more coarsely with the slider, but more finely with a semi-hidden spinbox

[Nathaniel Graham]

ngraham planned changes to this revision.
ngraham added a comment.


  Anyway I'm going to see if the textfield-next-to-the-slider approach works 
better (in conjunction with a warning message).

REPOSITORY
  R104 KScreen

REVISION DETAIL
  https://phabricator.kde.org/D24321

To: ngraham, #vdg, #plasma, romangg
Cc: davidedmundson, ouwerkerk, GB_2, ndavis, cullmann, plasma-devel, LeGast00n, 
The-Feren-OS-Dev, jraleigh, fbampaloukas, ragreen, ZrenBot, ngraham, alexeymin, 
himcesjf, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D24321: [KCM] Scale more coarsely with the slider, but more finely with a semi-hidden spinbox

[Christoph Cullmann]

cullmann added a comment.


  Hi, I thought about this a bit more ;)
  
  I really think we shall limit the minimal increase to 0.25, without any 
advanced field. Perhaps the range should be larger, like 1-4, if some people 
get "really" high DPI screens.
  
  Rational:
  
  1. For small 0.1 changes: Just change your font size, we did that always for 
the old non-hidpi world were displays did differ a bit in the DPI, that works 
without any glitches
  
  2. Anything below 0.25 will just break half of our applications. For 
KTextEditor I did some hack in master that might avoid artifacts if you only 
scale with stuff like .25 or .5, it will still break with small stuff and most 
of our applications look horrible with small scalings, look at attached 
screenshot fo 1.1, do we really want to advertise that?
  
  F7481758: screenshot.png 
  
  Qt 5.14 will even have "opt-out" of fractional scaling and perhaps we even 
need to do that for some applications...

REPOSITORY
  R104 KScreen

REVISION DETAIL
  https://phabricator.kde.org/D24321

To: ngraham, #vdg, #plasma, romangg
Cc: davidedmundson, ouwerkerk, GB_2, ndavis, cullmann, plasma-devel, LeGast00n, 
The-Feren-OS-Dev, jraleigh, fbampaloukas, ragreen, ZrenBot, ngraham, alexeymin, 
himcesjf, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D24321: [KCM] Scale more coarsely with the slider, but more finely with a semi-hidden spinbox

[Christoph Cullmann]

cullmann added a comment.


  In D24321#540056 , @davidedmundson 
wrote:
  
  > > it would go into Plasma 5.17. :)
  >
  > There's still a feature freeze.
  
  
  At least moving away from 0.1 increases is actually a bugfix. Look at my 
konsole screenshot, similar artifacts can be created with most of our 
applications.
  (sadly still with 0.25/0.5, too, but at least not that often and you then can 
try to fix that by choosing some better font...)

REPOSITORY
  R104 KScreen

REVISION DETAIL
  https://phabricator.kde.org/D24321

To: ngraham, #vdg, #plasma, romangg
Cc: davidedmundson, ouwerkerk, GB_2, ndavis, cullmann, plasma-devel, LeGast00n, 
The-Feren-OS-Dev, jraleigh, fbampaloukas, ragreen, ZrenBot, ngraham, alexeymin, 
himcesjf, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D24321: [KCM] Scale more coarsely with the slider, but more finely with a semi-hidden spinbox

[David Edmundson]

davidedmundson added a comment.


  >   For small 0.1 changes: Just change your font size, we did that always for 
the old non-hidpi world were displays did differ a bit in the DPI, that works 
without any glitches
  
  I even used to do this in the new high DPI world. Before Qt had fractional 
scaling we had the slider it would adjust the font size until you reached 1.75 
then it would change the Qt scale too. It worked fine.

REPOSITORY
  R104 KScreen

REVISION DETAIL
  https://phabricator.kde.org/D24321

To: ngraham, #vdg, #plasma, romangg
Cc: davidedmundson, ouwerkerk, GB_2, ndavis, cullmann, plasma-devel, LeGast00n, 
The-Feren-OS-Dev, jraleigh, fbampaloukas, ragreen, ZrenBot, ngraham, alexeymin, 
himcesjf, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D24321: [KCM] Scale more coarsely with the slider, but more finely with a semi-hidden spinbox

[Christoph Cullmann]

cullmann added a comment.


  In D24321#540218 , @davidedmundson 
wrote:
  
  > >   For small 0.1 changes: Just change your font size, we did that always 
for the old non-hidpi world were displays did differ a bit in the DPI, that 
works without any glitches
  >
  > I even used to do this in the new high DPI world. Before Qt had fractional 
scaling we had the slider it would adjust the font size until you reached 1.75 
then it would change the Qt scale too. It worked fine.
  
  
  Perhaps such a mixed approach might even make more sense.
  
  As said, any scaling like 1.2 will not work with most of our applications, 
see above Konsole.
  
  With "a lot" of work, stuff like 1.25 or 1.5 will work like in KTextEditor by 
adjusting the fonts internally a bit to avoid sub-pixel jitter per line.
  
  I think we shall really avoid to expose bad scale factors to users.

REPOSITORY
  R104 KScreen

REVISION DETAIL
  https://phabricator.kde.org/D24321

To: ngraham, #vdg, #plasma, romangg
Cc: davidedmundson, ouwerkerk, GB_2, ndavis, cullmann, plasma-devel, LeGast00n, 
The-Feren-OS-Dev, jraleigh, fbampaloukas, ragreen, ZrenBot, ngraham, alexeymin, 
himcesjf, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D24321: [KCM] Scale more coarsely with the slider, but more finely with a semi-hidden spinbox

[Nathaniel Graham]

ngraham added a comment.


  In D24321#540218 , @davidedmundson 
wrote:
  
  > >   For small 0.1 changes: Just change your font size, we did that always 
for the old non-hidpi world were displays did differ a bit in the DPI, that 
works without any glitches
  >
  > I even used to do this in the new high DPI world. Before Qt had fractional 
scaling we had the slider it would adjust the font size until you reached 1.75 
then it would change the Qt scale too. It worked fine.
  
  
  Is there any technical barrier to returning to this? What was the UI like 
before? Was there a visual relationship between the scaling UI and the Fonts 
KCM, or did the former simply update the latter?

REPOSITORY
  R104 KScreen

REVISION DETAIL
  https://phabricator.kde.org/D24321

To: ngraham, #vdg, #plasma, romangg
Cc: davidedmundson, ouwerkerk, GB_2, ndavis, cullmann, plasma-devel, LeGast00n, 
The-Feren-OS-Dev, jraleigh, fbampaloukas, ragreen, ZrenBot, ngraham, alexeymin, 
himcesjf, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D24321: [KCM] Scale more coarsely with the slider, but more finely with a semi-hidden spinbox

[Roman Gilg]

romangg requested changes to this revision.
romangg added a comment.


  First the situation is different on X11 and Wayland:
  
  - On X11 KScreen sets Qt scale factors and some fonts dpi value through Xft. 
You can read it up here what was taken pretty much as it was from the old code: 
https://cgit.kde.org/kscreen.git/tree/kcm/kcm.cpp#n317
  - On Wayland KWin scales in OpenGl the whole image it receives from a client. 
There should be no artifacts visible with any scale factor, be it 1.1 or π.
  
  Looking at the provided screenshot with artifacts: This must be on X11 and I 
recognize these artifacts from when I tested different fractional scaling 
values on X11 months and years ago. Insofar this is no regression and is 
independent of the KCM rewrite. Which makes sense since the previous ui also 
offered 0.1 step sizes: 
https://www.dedoimedo.com/computers/plasma-hd-scaling.html
  
  In regards to Wayland: I don't agree that the 1.25 and 1.75 values are more 
important than 1.2, 1.3 and respectively 1.7, 1.8 values. That's just because 
you are used to it from other platforms. And that's a normal first reaction but 
you won't see a significant size difference between 1.2 and 1.25. Try it with 
1.2 and 1.3: even here the difference is minimal.
  
  What I definitely don't want for Wayland: recommending to users to set the 
size of their UI through the overall scaling value on the one side and on the 
other side through font size. I know some proficient members of our community 
know how to do that and think it's ok because it was always like that and it 
comes naturally to them. But to other users it's difficult or cumbersome to do.
  
  Conclusion: Leave it as it is on Wayland. It works fine there and gives user 
a way more fine-grained level of control than with .25 steps only. On X11 a 
separate isolated bug fix to this old known 
 problem with artifacts must be 
proposed.

REPOSITORY
  R104 KScreen

REVISION DETAIL
  https://phabricator.kde.org/D24321

To: ngraham, #vdg, #plasma, romangg
Cc: davidedmundson, ouwerkerk, GB_2, ndavis, cullmann, plasma-devel, LeGast00n, 
The-Feren-OS-Dev, jraleigh, fbampaloukas, ragreen, ZrenBot, ngraham, alexeymin, 
himcesjf, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D24321: [KCM] Scale more coarsely with the slider, but more finely with a semi-hidden spinbox

[Christoph Cullmann]

cullmann added a comment.


  ;=) I talked only about the Qt HiDPI scaling code paths.
  
  For any other scaling I don't care, as that should be application 
transparent, like you say.
  But if Wayland really just scales up the stuff via GL fonts will look 
terrible.
  
  And no, its non-trivial to fix there any artifacts for strange scales and it 
makes there computation wise a very large different if the scale factor is 1.2 
or 1.25, as the later is something you can sanely compute things with ;)
  Therefore I really would like to have only some larger scaling steps set for 
the QT_SCALE_FACTOR... stuff and for the smaller things just some font 
adjustments.

REPOSITORY
  R104 KScreen

REVISION DETAIL
  https://phabricator.kde.org/D24321

To: ngraham, #vdg, #plasma, romangg
Cc: davidedmundson, ouwerkerk, GB_2, ndavis, cullmann, plasma-devel, LeGast00n, 
The-Feren-OS-Dev, jraleigh, fbampaloukas, ragreen, ZrenBot, ngraham, alexeymin, 
himcesjf, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D24321: [KCM] Scale more coarsely with the slider, but more finely with a semi-hidden spinbox

[Christoph Cullmann]

cullmann added a comment.


  Hmm, I just tried here a Wayland session, and yes, the KCM has there just 
some 1x/2x combobox and my fonts are maximal ugly compared to some export 
QT_SCALE_FACTOR=2 + starting a Qt application (on Wayland).
  But I must try that at home on real HiDPI screens, perhaps my test is 
suboptimal here.

REPOSITORY
  R104 KScreen

REVISION DETAIL
  https://phabricator.kde.org/D24321

To: ngraham, #vdg, #plasma, romangg
Cc: davidedmundson, ouwerkerk, GB_2, ndavis, cullmann, plasma-devel, LeGast00n, 
The-Feren-OS-Dev, jraleigh, fbampaloukas, ragreen, ZrenBot, ngraham, alexeymin, 
himcesjf, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D24321: [KCM] Scale more coarsely with the slider, but more finely with a semi-hidden spinbox

[Roman Gilg]

romangg added a comment.


  In D24321#540433 , @cullmann wrote:
  
  > ;=) I talked only about the Qt HiDPI scaling code paths.
  
  
  In this case I recommend studying the bug report I linked. There is also a 
patch attempt in Qt but it got closed for some reason.
  
  > For any other scaling I don't care, as that should be application 
transparent, like you say.
  >  But if Wayland really just scales up the stuff via GL fonts will look 
terrible.
  
  They are scaled down via Gl to match the fractional part of the scaling 
value. Applications provide pre-scaled buffers of integer factors 2, 3, 4 and 
so on.
  
  > And no, its non-trivial to fix there any artifacts for strange scales and 
it makes there computation wise a very large different if the scale factor is 
1.2 or 1.25, as the later is something you can sanely compute things with ;)
  >  Therefore I really would like to have only some larger scaling steps set 
for the QT_SCALE_FACTOR... stuff and for the smaller things just some font 
adjustments.
  
  Don't see a reason for that. Never heard about necessity in Gl to only 
calculate with certain floating values for best image quality. But if you can 
provide some source for that I would be interested in studying that. Can't say 
I see problems here in a Wayland session though, currently using a scaling 
factor of 1.8.

REPOSITORY
  R104 KScreen

REVISION DETAIL
  https://phabricator.kde.org/D24321

To: ngraham, #vdg, #plasma, romangg
Cc: davidedmundson, ouwerkerk, GB_2, ndavis, cullmann, plasma-devel, LeGast00n, 
The-Feren-OS-Dev, jraleigh, fbampaloukas, ragreen, ZrenBot, ngraham, alexeymin, 
himcesjf, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D24321: [KCM] Scale more coarsely with the slider, but more finely with a semi-hidden spinbox

[Christoph Cullmann]

cullmann added a comment.


  In D24321#540437 , @romangg wrote:
  
  > In D24321#540433 , @cullmann 
wrote:
  >
  > > ;=) I talked only about the Qt HiDPI scaling code paths.
  >
  >
  > In this case I recommend studying the bug report I linked. There is also a 
patch attempt in Qt but it got closed for some reason.
  
  
  You can't patch that issues in Qt if e.g. your application relies on facts 
like you paint 10 lines and you don't get some rounding errors all the time ;)
  
  > 
  > 
  >> For any other scaling I don't care, as that should be application 
transparent, like you say.
  >>  But if Wayland really just scales up the stuff via GL fonts will look 
terrible.
  > 
  > They are scaled down via Gl to match the fractional part of the scaling 
value. Applications provide pre-scaled buffers of integer factors 2, 3, 4 and 
so on.
  
  Hmm, but that means you still set QT_SCALE_ to some non-fractional thing 
like 2, 3, 4 and the only fine adjust, that makes sense.
  Thought for me it did look like the small scale window was up-scaled in my 
try with the 2x combobox field.
  
  > 
  > 
  >> And no, its non-trivial to fix there any artifacts for strange scales and 
it makes there computation wise a very large different if the scale factor is 
1.2 or 1.25, as the later is something you can sanely compute things with ;)
  >>  Therefore I really would like to have only some larger scaling steps set 
for the QT_SCALE_FACTOR... stuff and for the smaller things just some font 
adjustments.
  > 
  > Don't see a reason for that. Never heard about necessity in Gl to only 
calculate with certain floating values for best image quality. But if you can 
provide some source for that I would be interested in studying that. Can't say 
I see problems here in a Wayland session though, currently using a scaling 
factor of 1.8.
  
  The issue is that you transform individual elements.
  
  e.g. if you have some list of X graphical elements with height "virtual" 
pixel 10. If you scale them by 1.1, you get not "real pixel" 11, you get some 
11.00100101010 something. If you later compute things like "10 * element size", 
you not get 110 pixel but again some weired stuff ;=)
  
  
https://www.exploringbinary.com/why-0-point-1-does-not-exist-in-floating-point/
  
  If you apply that as transform on the full texture, I can agree that it 
shouldn't be a real issue.
  But if it is applied as QT_SCALE... you will have the issue of rounding 
artifacts for the individual widgets/layout members that then sum up in weired 
ways. 
  You get already some artifacts with 1/2 or 1/4, but at least you can multiply 
that sanely (as long as your floating point numbers don't get enourmous).

REPOSITORY
  R104 KScreen

REVISION DETAIL
  https://phabricator.kde.org/D24321

To: ngraham, #vdg, #plasma, romangg
Cc: davidedmundson, ouwerkerk, GB_2, ndavis, cullmann, plasma-devel, LeGast00n, 
The-Feren-OS-Dev, jraleigh, fbampaloukas, ragreen, ZrenBot, ngraham, alexeymin, 
himcesjf, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D24321: [KCM] Scale more coarsely with the slider, but more finely with a semi-hidden spinbox

[Christoph Cullmann]

cullmann added a comment.


  Ok, tried Wayland now on my HiDPI setup.
  In Plasma's KCM I only have Scale 1x or 2x and that works ok, as one would 
think.
  But I see no way to set any more fine-grained scale to check if the scaling 
is nice for other values.
  The slider is for me only there for X11.

REPOSITORY
  R104 KScreen

REVISION DETAIL
  https://phabricator.kde.org/D24321

To: ngraham, #vdg, #plasma, romangg
Cc: davidedmundson, ouwerkerk, GB_2, ndavis, cullmann, plasma-devel, LeGast00n, 
The-Feren-OS-Dev, jraleigh, fbampaloukas, ragreen, ZrenBot, ngraham, alexeymin, 
himcesjf, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D24321: [KCM] Scale more coarsely with the slider, but more finely with a semi-hidden spinbox

[Christoph Cullmann]

cullmann added a comment.


  I will investigate the https://bugreports.qt.io/browse/QTBUG-66036 bug again, 
too :/
  Even with the rounding issues one gets over larger multiplications, it 
shouldn't be that buggy for short ones.

REPOSITORY
  R104 KScreen

REVISION DETAIL
  https://phabricator.kde.org/D24321

To: ngraham, #vdg, #plasma, romangg
Cc: davidedmundson, ouwerkerk, GB_2, ndavis, cullmann, plasma-devel, LeGast00n, 
The-Feren-OS-Dev, jraleigh, fbampaloukas, ragreen, ZrenBot, ngraham, alexeymin, 
himcesjf, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D24321: [KCM] Scale more coarsely with the slider, but more finely with a semi-hidden spinbox

[Christoph Cullmann]

cullmann added a comment.


  I got some more insight into https://bugreports.qt.io/browse/QTBUG-66036
  If one turns off anti-aliasing, in KTextEditor most of the evil artifacts 
disappear, but not all.

REPOSITORY
  R104 KScreen

REVISION DETAIL
  https://phabricator.kde.org/D24321

To: ngraham, #vdg, #plasma, romangg
Cc: davidedmundson, ouwerkerk, GB_2, ndavis, cullmann, plasma-devel, LeGast00n, 
The-Feren-OS-Dev, jraleigh, fbampaloukas, ragreen, ZrenBot, ngraham, alexeymin, 
himcesjf, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D24321: [KCM] Scale more coarsely with the slider, but more finely with a semi-hidden spinbox

[Christoph Cullmann]

cullmann added a comment.


  Ok, I wasted one evening on the rendering artifacts stuff.
  
  https://bugreports.qt.io/browse/QTBUG-66036
  
  I have now ugly workarounds in KTextEditor:
  
  1. no anti-aliasing, else fillRect misses to fill 1 pixel at the borders by 
rounding errors
  2. adjust the clip rect by one logical pixel to not miss 1 real device pixel 
sometimes

REPOSITORY
  R104 KScreen

REVISION DETAIL
  https://phabricator.kde.org/D24321

To: ngraham, #vdg, #plasma, romangg
Cc: davidedmundson, ouwerkerk, GB_2, ndavis, cullmann, plasma-devel, LeGast00n, 
The-Feren-OS-Dev, jraleigh, fbampaloukas, ragreen, ZrenBot, ngraham, alexeymin, 
himcesjf, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D24321: [KCM] Scale more coarsely with the slider, but more finely with a semi-hidden spinbox

[Dominik Haumann]

dhaumann added a comment.


  As far as I understand, the reasoning of @cullmann is that 0.1 cannot be 
accurately be represented by a computer. Following this discussion 
,
 the number 0.1 will turn into either 
0.0167332731531132594682276248931884765625 or 
0.155511151231257827021181583404541015625.
  
  And @cullmann's point here is: Do we really want to have calls of 
QPainter::scale() with these above numbers? It is quite obvious that you will 
never get any full pixels with such scaling factors.
  
  That's why i) proposing a coarser step width, and ii) numbers that CAN be 
represented lead to the proposed patch of 0.25, 0.5, 0.75, ... These numbers 
are perfectly representable by a computer without rounding artifacts, and 
multiplying with ints you may even have a chance of getting a nice int again in 
many cases, which is exactly what you want if you want, since the chance of 
getting full pixels is much higher.
  
  So +1 for this patch, it does make a lot of sense (in fact, based on the 
above reasoning, I'd even drop the option of setting 0.05, 0.1, ... via the 
advanced button). Please reconsider this patch.

REPOSITORY
  R104 KScreen

REVISION DETAIL
  https://phabricator.kde.org/D24321

To: ngraham, #vdg, #plasma, romangg
Cc: dhaumann, davidedmundson, ouwerkerk, GB_2, ndavis, cullmann, plasma-devel, 
LeGast00n, The-Feren-OS-Dev, jraleigh, fbampaloukas, ragreen, ZrenBot, ngraham, 
alexeymin, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, 
apol, mart

D24321: [KCM] Scale more coarsely with the slider, but more finely with a semi-hidden spinbox

[Christoph Cullmann]

cullmann added a comment.


  Even with my hacks for https://bugreports.qt.io/browse/QTBUG-66036 in current 
KTextEditor master (see https://bugs.kde.org/show_bug.cgi?id=390451) you will 
still get after every xx lines some stray artifact in some cases during 
selection if you have some 1.1 scaling.
  That still seems to be a remaining issue with selection painting. Not 
happening with proper scaling of 1.25 or 1.5 as nothing adds up multiplication.

REPOSITORY
  R104 KScreen

REVISION DETAIL
  https://phabricator.kde.org/D24321

To: ngraham, #vdg, #plasma, romangg
Cc: dhaumann, davidedmundson, ouwerkerk, GB_2, ndavis, cullmann, plasma-devel, 
LeGast00n, The-Feren-OS-Dev, jraleigh, fbampaloukas, ragreen, ZrenBot, ngraham, 
alexeymin, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, 
apol, mart

D24321: [KCM] Scale more coarsely with the slider, but more finely with a semi-hidden spinbox

[Nathaniel Graham]

ngraham updated this revision to Diff 67156.
ngraham added a comment.


  Take two on the UI

REPOSITORY
  R104 KScreen

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D24321?vs=67087&id=67156

BRANCH
  advanced-scaling-control (branched from master)

REVISION DETAIL
  https://phabricator.kde.org/D24321

AFFECTED FILES
  kcm/package/contents/ui/OutputPanel.qml
  kcm/package/contents/ui/Panel.qml
  kcm/package/contents/ui/main.qml

To: ngraham, #vdg, #plasma, romangg
Cc: dhaumann, davidedmundson, ouwerkerk, GB_2, ndavis, cullmann, plasma-devel, 
LeGast00n, The-Feren-OS-Dev, jraleigh, fbampaloukas, ragreen, ZrenBot, ngraham, 
alexeymin, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, 
apol, mart