Details
-
Bug
-
Resolution: Unresolved
-
Not Evaluated
-
None
-
6.10
-
None
Description
In the situation where you have both QtGui scaling enabled (via e.g. QT_SCALE_FACTOR) and OS-level DPR (e.g. running on macOS), you may end up with rendering artifacts.
For example QT_SCALE_FACTOR=1.25 on a 2x retina screen on macOS.
The reason for this is that QBackingStore applies the QtGui scale factor before passing on things to QPlatformBackingStore, but does so via integer-based APIs. As a result, any rounding error in the QtGui scaling is multiplied by the QPlatformBackingStore layer.
For example, a beginPaint of logical width 10 will result in a width of 12.5 when applying QT_SCALE_FACTOR=1.25, which is rounded to 13 and passed on to QPlatformBackingStore, and then multipled by 2, resulting in a painted width of 26, when the true width should be 25 (10*1.25*2).
Fixing this by passing things along to QPlatformBackingStore as QRectF would seem like a good approach, except we use QRegion for the API layer, and QRegion surprisingly doesn't have a QRegionF companion đ˘
Another (bigger) change would be to move the QHighDpiScaling responsibility from QtGui, and down to the platform layer, where platforms that don't have native DPR would use QHighDpiScaling, leaving the scaling calculations in a single place in the platform layer rather than passed through API boundaries.Â
Attachments
Gerrit Reviews
For Gerrit Dashboard: QTBUG-138261 | ||||||
---|---|---|---|---|---|---|
# | Subject | Branch | Project | Status | CR | V |
658879,7 | Account for already transformed coordinates in QRhiBackingStore::flush | dev | qt/qtbase | Status: NEW | 0 | 0 |