invisible window when a window is mapped but not yet drawn on by the process mapping it
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Compiz Core |
Fix Released
|
Low
|
Sam Spilsbury | ||
compiz (Ubuntu) |
Fix Released
|
Low
|
Sam Spilsbury |
Bug Description
The following case can cause an invisible window to be created:
Display *d = XOpenDisplay (NULL);
w = XCreateWindow (... InputOutput ...);
XMapWindow (d, w);
XEvent e;
do { XNextEvent (dpy, &e); } while (e.type != Expose);
}
In this case, the window will be mapped but the pixmap will never be touched and so it will never receive a damage event. Core does not paint windows which have net yet been damaged to avoid race conditions where a plugin may not have finished painting its scene into the window.
However, if the window *never* gets damaged, then its window *and* decorations will be invisible as it is removed from the paint stack completely by the composite plugin. We should not paint the undamaged window itself until it is drawn on, but still paint the decoration in order to indicate to users of such buggy apps that their window is there.
Related branches
- Robert Carr (community): Approve
-
Diff: 81 lines (+16/-9)2 files modifiedplugins/composite/src/window.cpp (+4/-4)
plugins/opengl/src/paint.cpp (+12/-5)
Changed in compiz-core: | |
status: | New → Confirmed |
status: | Confirmed → In Progress |
importance: | Undecided → Low |
assignee: | nobody → Sam Spilsbury (smspillaz) |
milestone: | none → 0.9.6 |
Changed in compiz (Ubuntu): | |
status: | New → Fix Committed |
Changed in compiz-core: | |
status: | In Progress → Fix Committed |
Changed in compiz (Ubuntu): | |
importance: | Undecided → Low |
assignee: | nobody → Sam Spilsbury (smspillaz) |
milestone: | none → ubuntu-11.10 |
Changed in compiz-core: | |
status: | Fix Committed → Fix Released |
This bug was fixed in the package compiz - 1:0.9.6-0ubuntu1
---------------
compiz (1:0.9.6-0ubuntu1) oneiric; urgency=low
* New upstream release 0.9.6: decorator (LP: #856096)
- Windows which are marked transients of docks should be treated like docks (LP: #860397)
- Applications which create multiple windows that are transients of each other can be given invalid stack positions (LP: #858625)
- race condition in configureXWindow causes unpredicatable window geometry changes (LP: #860304)
- invisible window when a window is mapped but not yet drawn on by the process mapping it (LP: #860286)
- resizing bugs with xterm (LP: #854725)
- Cannot open a window that starts iconified (LP: #732997)
- maximized windows fail to update their input extents when undecorated (LP: #853734)
- Clicking on a tweet/message link sometimes does not work (LP: #790565)
- crash on closing a window (LP: #856015)
- Windows move to 0,0 on compiz restarts (LP: #858629)
- windows that are decorated while resizing can cause incorrect resize results (LP: #860306)
- remove transient window handling from unity-window-
-- Didier Roche <email address hidden> Wed, 28 Sep 2011 14:15:21 +0200