neopand@mist.cs.orst.edu (Deepak Neopane) (05/13/91)
-- _______________________________________________________________ | Deepak Neopane | INTERNET:neopand@prism.cs.orst.edu| | 618 Finley Hall, OSU | BITNET :neopaned@orstvm.bitnet | |_Corvallis,_OR 97331-1208|_503-737-8633______________________|
ekberg@asl.dl.nec.COM (Tom Ekberg) (05/14/91)
> [no body]
I'm not sure if this will work for you, but on another window system I
encountered this with a bouncing ball screen saver program. This program would
draw a sphere (well, it really was a circle, 2-D not 3-D) showing it bouncing
against the sides of the screen and into other spheres. For the sake of
discussion I'll ignore the multi-sphere case. The problem is that if one
starts with a sphere at one location, how does one draw it at another location
a small distance away. When a sphere is moved, the original program would
erase the sphere (via XOR (yes, it was monochrome)) and draw the sphere at its
new location (XOR again). This approach is simple and easy to implement. It
also introduced a great deal of flicker when the sphere didn't move far since
the `middle' of the sphere would be erased and then drawn again.
My solution was to generate a pixmap which would contain just those parts of
the image which would change, in this case, it would be two crescent shaped
objects. Drawing with XOR would cause one of the crescents to erase the
trailing edge and the other crescent would draw the leading edge. Flicker was
reduced to a minimum and the drawing looked MUCH more natural.
Now, you specifically mentioned filled rectangles, but the same concept
applies. You will have two or four rectangles forming the image you need to
draw instead of two crescents. One of the two, (or two of the four) rectangles
will erase the trailing edge and the other(s) will draw the leading edge.
Of course, if the two images do not intersect then you have to erase the image
and draw it at its new location anyway. Also, if you are using something other
than a monochrome server then the XOR operation is a bit more complex. Refer
to the FAQ for more discussion on that. Subject 112 says "Why doesn't GXxor
produce mathematically-correct color values?" in the May 1991 edition.
I'm sure you can think up other variations to the same theme using clipping
rectangles, or something else.
-- tom, ekberg@asl.dl.nec.com (x3503)