1. Run the attached software: wlscalefactor.tar.gz with Wayland scaling 200% and set env var:

• QT_SCALE_FACTOR=0.875 which gives DPR 1.75
• QT_SCALE_FACTOR=0.5 which gives DPR 1.0
• QT_SCALE_FACTOR=1.5 which gives DPR 3.0

2. Press mouse on one of list items and move mouse to change the selection.

Also see video: wlscalefactor.mp4

—
Update

Koloutpaint running on 200% compositor scale with QT_SCALE_FACTOR=0.5 which behaves like 100% scale - nothing is painted there, I moved mouse over the canvas, we can see a lot of garbage on canvas:

Attached test application running on 200% compositor scale with QT_SCALE_FACTOR=0.5 which behaves like 100% scale - we can see 1px remaining highlight lines and 1px transparent lines which shows the desktop background:

The idea is to use QT_SCALE_FACTOR in Wayland to run application in different scaling than compositor (for example run application with 100% or 175% scaling when compositor runs in 200% scaling).
On Wayland QT_SCALE_FACTOR has to be fractional to compensate the compositor scaling (e.g. QT_SCALE_FACTOR=0.5 to achieve 100% application scaling in 200% compositor scaling). It's good to test applications with various scales without changing the compositor scale and also when we want to use one application with different scale for various reasons (e.g. one application is too large in 200% and runs fine with fractional scale where other applications are good in 200% and/or runs bad in fractional scale).

The problem with visual glitches comes from rounding regions to integers instead of passing not scaled regions to platform backing store and let it handle it without losing the real region.

Attached commit fixes the issue, I can no longer see any visual glitches.