Composite and bit gravity
Keith Packard
keithp at keithp.com
Mon Nov 15 09:13:16 PST 2004
Around 23 o'clock on Nov 12, Soeren Sandmann wrote:
> When a redirected window is resized, a new pixmap is allocated, but
> currently the old bits are not copied to the new pixmap until they are
> needed by CopyWindow. This breaks bit gravity, which at least GTK+,
> and I'd assume other toolkits, rely on.
Is it that CopyWindow isn't getting called? I can see how that might
happen when the bits don't move on the screen.
If you look in xserver CVS, you'll see the following comment for compint.h:
Revision 1.7
date: 2003-11-20 03:31:29 +0000; author: keithp; state: Exp; lines: +31 -2
* composite/compalloc.c: (compFreePixmap), (compReallocPixmap):
* composite/compext.c:
* composite/compinit.c: (compCloseScreen), (compScreenInit):
* composite/compint.h:
* composite/compwindow.c: (compCheckRedirect),
(compPositionWindow), (compMoveWindow), (compResizeWindow),
(compChangeBorderWidth), (compCopyWindow):
* dix/window.c:
(Yes, these are all related changes). Rework window manipulation
while Composite is enabled. The basic problem was when the
window was resized, the offscreen pixmap would get resized and if
that shrunk, the eventual CopyWindow call would not be able to get
bits. Now, all resizes are managed by allocating a new pixmap
and hanging on to the old one until after all of the CopyWindow
calls are done.
A related change was to reset the borderClip back to the
parent-limited version when removing redirection from a window
so that the UnmapWindow operation within that uses the correct
value
There's also the problem that WindowGravity copies need access to the old
bits, so you really can't just copy the bits during the resize.
-keith
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20041115/984a4656/attachment.pgp>
More information about the xorg
mailing list