https://bugs.kde.org/show_bug.cgi?id=397767
David Edmundson <k...@davidedmundson.co.uk> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |FIXED
Latest Commit| |https://commits.kde.org/kwi
| |n/d485dfe7ef1910a7f66526103
| |88ae2d93cdec29f
Status|CONFIRMED |RESOLVED
--- Comment #9 from David Edmundson <k...@davidedmundson.co.uk> ---
Git commit d485dfe7ef1910a7f6652610388ae2d93cdec29f by David Edmundson.
Committed on 13/09/2018 at 09:19.
Pushed by davidedmundson into branch 'master'.
Avoid crash with on scripted window teardown with threaded quick render loop
Summary:
Qt render loops behave quite differently to each other.
KWin scripting as a workaround for another situation cleans
(17553e5a1fb72a92dbbff3fa6bc7d55b8f1a0123) handles tracking of script
windows by deleting the underlying window handle on hide.
This currently happens before the window gets the hideEvent.
Arguably this is a quirk with Qt, but in the current state:
- QSGThreadedRenderLoop deletes the platform window and cleans up
- We then get the hide() event. This no-ops because there's no window.
(else branch of case WM_TryRelease in qsgthreadedrenderloop.cpp)
- We carry on rendering animations despite having no platform
- undefined behaviour
Normally this isn't a problem as typically destruction of the platform window
happens only when a window is being deleted, we're messing with Qt
internals here.
If we make sure the QHideEvent is processed by the render loop first,
things seem fine.
Test Plan:
Ran QSG_RENDER_LOOP=threaded
Read output with scenegraph logging rules on
Reviewers: #kwin, broulik
Reviewed By: broulik
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D15025
M +2 -2 scripting/scripting.cpp
https://commits.kde.org/kwin/d485dfe7ef1910a7f6652610388ae2d93cdec29f
--
You are receiving this mail because:
You are watching all bug changes.
