Bug 514045

Summary:	QT Window not visible until it is repainted or fractional scaling is disabled
Product:	[Plasma] kwin	Reporter:	Mika Westphal <bugs.kde.org.reshuffle750>
Component:	general	Assignee:	KWin default assignee <kwin-bugs-null>
Status:	RESOLVED FIXED
Severity:	normal	CC:	bugs.kde.org.reshuffle750, kde
Priority:	NOR
Version First Reported In:	unspecified
Target Milestone:	---
Platform:	Other
OS:	Linux
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:
Attachments:	Shows the bug

Description Mika Westphal 2026-01-01 16:29:19 UTC

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

Comment 1 Mika Westphal 2026-01-01 16:31:31 UTC

Created attachment 188136 [details]
Shows the bug

Comment 2 David Edmundson 2026-01-01 16:42:00 UTC

This will be a client bug, please report there

>MakeMKV

Any others?

Comment 3 Mika Westphal 2026-01-01 16:53:56 UTC

(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?

Comment 4 Mika Westphal 2026-01-01 16:59:54 UTC

Also it is only happening on Wayland. When I use it with XWayland the scaling is no problem anymore

QT_QPA_PLATFORM=xcb makemkv

Comment 5 David Edmundson 2026-01-01 22:12:34 UTC

> 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.