Merge lp:~smspillaz/compiz-animation-plugin/compiz-animation-plugion.fix_940603 into lp:compiz-animation-plugin
Status: | Merged |
---|---|
Merged at revision: | 397 |
Proposed branch: | lp:~smspillaz/compiz-animation-plugin/compiz-animation-plugion.fix_940603 |
Merge into: | lp:compiz-animation-plugin |
Diff against target: |
27 lines (+5/-5) 1 file modified
src/animation.cpp (+5/-5) |
To merge this branch: | bzr merge lp:~smspillaz/compiz-animation-plugin/compiz-animation-plugion.fix_940603 |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Daniel van Vugt | Approve | ||
Review via email:
|
Description of the change
See LP #940603
== Problem ==
There is a corner case where a window, when it receives a ReparentNotify, would have its destroy reference incremented and then never decremented because an animation was never playing for it.
== Solution ==
Don't increment the destroy ref count of a window unless an animation is active.
It doesn't make any sense to increase the destroy reference count of a window
on CompWindowNotif
that window "could" be allowed - CompWindowNotif
on CompWindow::destroy (which under sane circumstances, should only ever be called
when the window is either reparented away from its parent or the root window
or when the window is destroyed).
In this case, we deregister all events on the window so it isn't possible to determine
through any normal means that a close animation is going to activate on the window. And
in any event, the unmap which causes close animations always comes before the DestroyNotify
or ReparentNotify anyways.
Even if the CompWindowNotif
or DestroyNotify, the tradeoff then comes between not playing animations for those corner case
windows or keeping ghost windows on screen because we kept a destroy reference and never
got rid of it. In this case, it is more sane to do the former.
== Tests ==
None ......
Looks good and seems to work OK.