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 <https://phabricator.kde.org/D24321#540437>, @romangg wrote:
  
  > In D24321#540433 <https://phabricator.kde.org/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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20191001/55582c50/attachment-0001.html>