SUMMARY When I use Qt based tools, some windows are not rendering until I hovered with the mouse over the elements or they get repainted in other ways. This happens only when fractional scaling is being used STEPS TO REPRODUCE 1. Open a QT app like MakeMKV 2. Open a second window in it like the about popup under help OBSERVED RESULT Until the widgets get repainted the window is not visible EXPECTED RESULT I can see the window SOFTWARE/OS VERSIONS Linux/KDE Plasma: Arch Linux KDE Plasma Version: 6.5.4 KDE Frameworks Version: 6.21.0 Qt Version: 6.10.1 Kernel: 6.18.2-arch2-1 Graphics Platform: Wayland GPU: RX 7900 XTX
Created attachment 188136 [details] Shows the bug
This will be a client bug, please report there >MakeMKV Any others?
(In reply to David Edmundson from comment #2) > This will be a client bug, please report there > > >MakeMKV > > Any others? No, not anymore. I had it mid 2024 in Qt Designer too but not now anymore So far, I've mostly noticed it in MakeMKV. However, since the window decoration (drawn by KWin) renders perfectly, but the client content lags behind until a hover event forces a repaint, it seems like a synchronization issue introduced by the fractional scaling mechanism. Even if MakeMKV is doing something non-standard, implies that the damage events are swallowed or delayed by the compositor in this specific scaling scenario. Is there a specific KWin rule or environment variable (like a specific rendering backend enforcement) that could force a correct repaint on map?
Also it is only happening on Wayland. When I use it with XWayland the scaling is no problem anymore QT_QPA_PLATFORM=xcb makemkv
> Is there a specific KWin rule No, it'll be client side. Please report to MakeMKV and link here. They might blame Qt, but I'll chase that with my Qt hat on if they do. >it seems like a synchronization issue introduced by the fractional scaling mechanism The client is guaranteed to have the right DPR at the time Qt asks it to do the first paint. But potentially the client is doing something unusual.