Composite and bit gravity
Owen Taylor
otaylor at redhat.com
Sat Nov 13 06:10:47 PST 2004
On Fri, 2004-11-12 at 23:46 +0100, 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. The pixels are simply not
> there when the gravity code runs.
>
> The attached patch fixes this by copying the pixels immediately.
>
> Another fix might be to somehow make the gravity code read the old
> pixels, but I think that would be more complicated. We can do this
> later if/when pixel copying becomes a bottleneck.
>
> And
>
> % diffstat gravity.patch
> compalloc.c | 26 ++++++++++++++++++++-
> compint.h | 1
> compwindow.c | 70 ----------------------------------------------------------- 3 files
> changed, 25 insertions(+), 72 deletions(-)
>
> is always nice.
Is this going to handle the case of making a window smaller with, say,
SW bit gravity where you go from
XXXXXXX AAAAA
XAAAAAA => AAAAA
XAAAAAA
As well as gravity, border width changes can result in shifts of of
pixels within the window's pixmap.
Also see bug 1788 that affects same the portion of compwindow.c.
Regards,
Owen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg/attachments/20041113/ad6b33c5/attachment.pgp>
More information about the xorg
mailing list