Account for already transformed coordinates in QRhiBackingStore::flushHEADdev

The implementation of QRhiBackingStore::flush uses rhiFlush, which
assumed that the incoming region and offset were in logical coordinates,
and then applied the sourceDevicePixelRatio to map them to device
coordinates.

This works for QWidgetRepaintManager::flush, which passes on the region
and offset in logical coordinates, but QRhiBackingStore::flush has logic
to pre-transform the coordinates from device independent to native for
the case where QtGui is doing the high-DPI scaling (Windows, Wayland,
Android, etc, as opposed to macOS/iOS where the OS does the scaling).

As a result QRhiBackingStore::flush would get pre-transformed
coordinates that it then passed on to rhiFlush, mapping it as
if it was in logical coordinates.

Fixing this by inverting the transform in QRhiBackingStore::flush is not
trivial due to fractional DPR accumulation, which QBackingStore::flush
already takes care of.

Instead we pass on the DPR coming from the platform window, which will
typically be 1 on platforms like Windows and Android, but may be non-1
when testing with QT_SCALE_FACTOR on e.g. macOS. This results in the
right transformation applied in QBackingStoreDefaultCompositor::flush.

We still need to pass the source DPR, as QBackingStoreDefaultCompositor
relies on the source DPR to compute the window-relative source rect,
which needs to reflect the DPR of the raw source pixels.

Tested with every combination of QT_WIDGETS_RHI, QT_SCALE_FACTOR,
QT_WIDGETS_HIGHDPI_DOWNSCALE, on 1x and 2x screens, with both integer
and fractional scale factors.

Note, in testing this it was revealed that we have an issue with
rounding errors when using both QtGui level high-DPI scaling, e.g.
via QT_SCALE_FACTOR=1.25 and OS-level scaling (e.g. 2x retina on
macOS). In this case QBackingStore applies the QtGui scale, but
rounds before passing things on to the platform, where we then
multiply the rounding error. The reason we don't see any visual
artifacts for this right now with QT_WIDGETS_RHI is that even though
we clear too much in beginPaint, the rhiFlush code path used by
QWidgetRepaintManager directly does not do any QHighDpiScaling,
so we end up not flushing the wrongly cleared pixels.

Solving this is not straight forward, as the QPlatformBackingStore
API surface uses QRegion extensively, and we surprisingly don't
have a QRegionF.

Fixes: QTBUG-128794
Fixes: QTBUG-133549
Fixes: QTBUG-128457
Fixes: QTBUG-128422
Fixes: QTBUG-121757
Task-number: QTBUG-138261
Pick-to: 6.10 6.9 6.8
Change-Id: I47884c28ef0ba8223ee16229d21e9c38801ae11f
Reviewed-by: Assam Boudjelthia <[email protected]>

0 files changed, 0 insertions, 0 deletions