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