problems with XCopyArea

I encountered this problem when coding smooth scrolling for rxvt

scrolling foreign pixels

Rxvt is told by the client application (think shell) to scroll. It tries to accelerate by XCopyArea.

But before X server executes the XCopyArea, the source region is somehow changed. This results in "foreign pixels" being moved. "Foreign" as pixels inherited from another window which was obscuring ours at some point.

Example

We make 2 requests of XCopyArea. The first one would move obscured rectangle to a visible part, and the second copies the just-copied rectangle to another place. We see, that we are told about a problem only for the 1st request, but the 2nd one is influenced too.

This can happen in these cases:

something obscures it in between .... we would get GraphicExpose, ok!
something obscures it but stops obscuring in time (the obsuring window is either unmapped or moved away), so the area is exposed again, but, since we use Background None, the intruder window's contents remains, drawn over the source region, which will get moved to destination rectangle.

Solution: record the change/movements (keep a list of pairs request-number . movement, and when we finally get the Expose event -- a rectangle, apply the movement to it too, and refresh pixels on the resulting rectangle. Discard the pairs when we get event w/ that request commited (this is indicated in the 'serial' slot of the event).

a window un-obscures the source region! When we issue the XCopyArea request, we are not aware that the source is obscured (that's my presumption, and fact, but i don't know now, if this can be tracked). This is a small modification of case 2, and solved in the same way.

Solution:

When issueing a sequence of XCopyArea, I have to keep a sequence of this info (request-sequence-number . movement); discard them when I know that the request-sequence-number has been committed (i.e. by watching the 'serial' slot in events), and on Expose I have to apply a mapping to see where will the exposed rectangle be after the already issued sequence of (pixel moving) commands.

Keep a list of (rectangle & move). When we get a GraphicsExpose for a move, we start from that move, and mark as wrong all rectangles which are images under composition of the moves (in the list).

http://mail.gnome.org/archives/gtk-list/1997-December/msg00254.html

related (pixmap -> window blits vs NoExpose) http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6480051

Updated: 2006-10-24

Home / Index Agenzia matrimoniale Maruska google rev