geb@amber.Rational.COM (Gary Barnes) (08/18/89)
If an application does an XCopyArea and part of the source drawable is obscured then the application can/will get a GraphicsExpose event to let it know that it will have to redraw part of what it wanted to merely copy. That's fine and pretty obvious. Let's imagine the situation where the application window is partially obscured by some other window and the user moves or destroys the obscuring window just as the application is preparing its XCopyArea request. The application window becomes unobscured and an Expose event is generated. It is quite possible that the XCopyArea request and the Expose event will pass each other in the network. This means that the Expose event arrives at the application after the XCopyArea has left; so the application redraws that area and only that area. It also means that the XCopyArea request gets to the server after the exposure of the obscured portion of the window; so the server generates a NoExpose event rather than a GraphicsExpose event. The general result is that now there is an unsightly (probably white) blotch on some portion of the application window and the user, since he has to request some sort of redraw operation to fix up the window, begins to form a negative opinion of "this $%**$#$ program that can't even draw right". Two questions: 1) This *can* happen right? Especially given "large" network delays or "heavily" loaded servers or hosts. 2) Is there anything "good" that can be done about it? The appliation and always redraw *all* of its window for any Expose event. This seems extreme in the case of a graphics intensive application, eg. CAD. Presumably the application could keep Regions around that describe the last N XCopyArea/XCopyPlanes that have been sent but for which it has not yet received NoExpose/GraphicsExpose events. It would then compare the source region for each Copy with any Expose regions that might come along. If any Expose arrives that references any portion of some Copy's source region then the application could redraw not only the Expose region but also the destination region of the Copy. This seems a bit tedious and it uses memory as well as increasing application complexity. I originally thought, "Aha! Xterm must handle this, how does Xterm do it?" But, as it turns out, Xterm doesn't appear to worry about this. Is it a non-problem for some reason I havent thought of? Gary E. Barnes geb@Rational.com
rws@EXPO.LCS.MIT.EDU (08/18/89)
1) This *can* happen right?
Sure.
2) Is there anything "good" that can be done about it?
Yes.
Presumably the application could keep Regions around that describe the
last N XCopyArea/XCopyPlanes that have been sent but for which it has
not yet received NoExpose/GraphicsExpose events.
Right. Note that you also have to update the regions of any outstanding copies
if they intersect a later copy. For many applications, like those that just
scroll, this can be simplified a lot.
It would then compare the source region for each Copy with any Expose
regions that might come along.
No, you can use sequence numbers, which is a lot simpler.
This seems a bit tedious and it uses memory as well as increasing
application complexity.
Well, yes, unless somebody encapsulates it in some generic routines for reuse.
If you don't like it, you can always go synchronous, and simply wait for the
event to come back before doing any more graphics ops.
But, as it turns out, Xterm doesn't appear to worry about this.
Haven't looked at the code recently, but it's *supposed* to worry about this.