Bug 487082

Summary:	Not all screens update on window re-paints when using Zoom effect on Wayland
Product:	[Plasma] kwin	Reporter:	Ritchie Frodomar <ritchie>
Component:	wayland-generic	Assignee:	KWin default assignee <kwin-bugs-null>
Status:	CONFIRMED ---
Severity:	normal	CC:	kdedev, szaszm, xaver.hugl
Priority:	NOR	Keywords:	wayland-only
Version First Reported In:	6.0.4
Target Milestone:	---
Platform:	Other
OS:	Linux
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:
Attachments:	Right-click menu partially painted on one screen but not the other

Description Ritchie Frodomar 2024-05-16 05:22:10 UTC

SUMMARY
When using multiple displays with the Zoom effect on Wayland, not all screens update when a window needs to re-paint. This is most notable when typing in a text field, and appeasrs as if keys are being dropped.

STEPS TO REPRODUCE
1. Plug two or more displays into your system
2. Open Konsole on display 1
3. Zoom in to display 1, and type into Konsole until the cursor reaches display 2.
4. Continue typing, slowly, and observe keystrokes appearing to be dropped.
5. When you see that, either wait a bit or move your mouse. Notice the "dropped" key was never dropped, the display was just never repainted on time so you never saw it.
6. Repeat steps 5, swapping ddisplay 1 with display 2.

OBSERVED RESULT
If the user has more than one display, and is zoomed in, un-focused displays appear to update less frequently even though they need to. Unfocused displays being displays other than the one on which the currently focused window is placed when zoomed out.

The animation of zooming in and out of the screen isn't affected by this. Toggling color inversion does get affected, one screen will occasionally appear un-inverted when the other is inverted. The Window verview animation doesn't cause this, but the Tiling Editor one does (more noticeable on my system when closing tiling editor.)

EXPECTED RESULT
All displays on which re-painting windows are visible should be re-painted at the same time so as to not cause them to go out-of-sync with each other.

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Arch Linux 6.8.9-arch1-2 (64-bit)
KDE Plasma Version: 6.0.4
KDE Frameworks Version: 6.2.0
Qt Version: 6.7.0

ADDITIONAL INFORMATION
Both my screens are on the same GPU
GPU: AMD RX 7600XT
Screen 1: 32" 3840x2160, HDMI, 60Hz, no variable refresh rate
Screen 2: 32" 3840x2160, DisplayPort, 60Hz, no variable refresh rate

Both screens are at 100% display scale

This bug does not affect X11.

Comment 1 Ritchie Frodomar 2024-05-17 02:16:01 UTC

After looking at the code for Kwin's Zoom effect (specifically ZoomEffect::zoomIn() in zoom.cpp), I see why zooming in/out/around the screen doesn't cause these repaint issues.

At the very end, there's a call to effects->addRepaintFull() - which ultimately tells the compositor to repaint the entire scene.

With guidance, I could likely submit a merge request that fixes this for partial repaints. I just don't know enough of how it works yet.

Comment 2 Ritchie Frodomar 2024-05-17 22:07:39 UTC

Created attachment 169583 [details]
Right-click menu partially painted on one screen but not the other

Managed to capture the same bug happening in a different way. If you're able to right-click without moving the mouse or otherwise triggering another repaint, you can get a context menu to appear on one screen but not the other.

Same happens if you're able to dismiss the right-click menu without causing an additional repaint.