Bug 477199

Summary: KWin doesn't redraw the screen after a fullscreened app closes in some cases
Product: [Plasma] kwin Reporter: Devin Lin <espidev>
Component: generalAssignee: KWin default assignee <kwin-bugs-null>
Status: RESOLVED FIXED    
Severity: major CC: bednarczyk.pawel, bizyaev, nate, xaver.hugl
Priority: NOR Keywords: qt6
Version First Reported In: master   
Target Milestone: ---   
Platform: Other   
OS: Linux   
Latest Commit: https://invent.kde.org/plasma/kwin/-/commit/7f9cbbaa98c4cd633319e45e9a1100ea58f12840 Version Fixed/Implemented In:
Sentry Crash Report:
Attachments: QML snippet that opens a fullscreen window with a window exit button
Video reproducing the issue

Description Devin Lin 2023-11-18 18:25:57 UTC 
Created attachment 163273 [details]
QML snippet that opens a fullscreen window with a window exit button

SUMMARY
I seem to be encountering an issue where if a fullscreened app closes, the app doesn't get removed from the screen visually, and looks like its still open.

I originally this issue in Plasma Mobile with the initialstart wizard, when the fullscreen app closes thinking it was a freeze: https://invent.kde.org/plasma/plasma-mobile/-/issues/265

I can't seem to reproduce it when logged into a Plasma Desktop session, but I can reproduce it when running Plasma Desktop in kwin's windowed mode. 

Attached is a QML snippet that can be used for testing.

STEPS TO REPRODUCE
1. Open Plasma in KWin's windowed mode (QT_QPA_PLATFORM=wayland dbus-run-session kwin_wayland plasmashell)
2. Open a terminal and run the snippet attached (qmlscene-qt6 ./fullscreen-test.qml)
3. Press the "close" button

OBSERVED RESULT
See that it doesn't clear the screen.

Clicking on the bottom left to trigger the screen to redraw (open app launcher)

EXPECTED RESULT
The screen is cleared since the app has closed.

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Fedora
KDE Plasma Version:  Plasma 6 git master
Qt Version: 6.6

ADDITIONAL INFORMATION
See video attached as well for the example.
Comment 1 Devin Lin 2023-11-18 18:27:54 UTC 
Created attachment 163274 [details]
Video reproducing the issue
Comment 2 Pawel 2023-11-19 15:11:13 UTC 
I can reproduce this as well by launching a game from steam in full screen and then quitting to desktop. The screen seems to be stuck on the last frame. Clicking alt tab seems to trigger a refresh and a screen repaint. Always reproducible with Halls of Torment on AMf hardware.
Comment 3 Nate Graham 2023-11-30 22:43:22 UTC 
I was able to reproduce this earlier, but no longer can with today's packages/git master. Is anyone else still able to reproduce it when using the latest git commits?
Comment 4 Bug Janitor Service 2023-12-15 03:46:02 UTC 
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!
Comment 5 Devin Lin 2023-12-15 04:08:08 UTC 
I still seem to experience the bug.
Comment 6 Zamundaaa 2023-12-15 14:37:20 UTC 
Yeah I'm sometimes seeing this too. See https://invent.kde.org/plasma/kwin/-/merge_requests/4447 for a potential fix / workaround
Comment 7 Bug Janitor Service 2024-01-09 15:05:38 UTC 
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/4860
Comment 8 Zamundaaa 2024-01-09 17:22:31 UTC 
Git commit 7f9cbbaa98c4cd633319e45e9a1100ea58f12840 by Xaver Hugl.
Committed on 09/01/2024 at 18:06.
Pushed by zamundaaa into branch 'master'.

core/renderloop: improve frame scheduling heuristics with VRR

Instead of checking for fullscreen windows and deciding whether or not to schedule repaints
based on that, check if the active window is refreshing fast enough to be reasonable for vrr.
For automatic mode, vrr is also enabled with the active window instead of the direct scanout
candidate.
Related: bug 478680

M  +9    -6    src/compositor.cpp
M  +1    -0    src/core/output.h
M  +10   -6    src/core/renderloop.cpp
M  +1    -6    src/core/renderloop.h
M  +2    -1    src/core/renderloop_p.h
M  +21   -0    src/scene/surfaceitem.cpp
M  +7    -0    src/scene/surfaceitem.h

https://invent.kde.org/plasma/kwin/-/commit/7f9cbbaa98c4cd633319e45e9a1100ea58f12840