On Thu, 2007-11-29 at 20:03 +0100, Richard Boaz wrote: > > To illustrate: I have been called once, and GTK+ has drawn to the double > buffer pixmap as you say. I was partially obscured and am now re-exposed, > i.e., the main loop calls me again specifying an invalidated rectangle via > the GdkEvent structure. > > Do I: > 1) redraw the entire picture since I've been called, ignoring all else, > knowing this will result in a fully refreshed screen? > > 2) redraw only that part which was obscured (rectangle parameters > provided), having to determine programmatically what drawing commands > actually constitute refreshing the obscured portion? > > 3) know that my drawing hasn't changed its state since the last complete > draw and doesn't need to be redrawn at all since upon exiting this call, > the double buffer I had previously written to still contains my drawing > and will physically refresh only the rectangle which was passed to the > expose handler for re-exposure? > > Naturally I will demand that the third option is really the only > acceptable answer since: > > 1) option 1 is a complete waste of resources when I have to process 100 > million data points for drawing to the screen (I exaggerate not). > > 2) option 2 is simply impossible to make a one-to-one calculation as to > which pixels must be refreshed, programmatically. for many (perhaps even for an overwhelming majority of applications (2) works just fine. if you application can't do this cheaply, then your approach is the right way. > If the third option is how GTK+ handles this scenario (more kudos...), > then the expose handler would look something like?: no, GTK discards the bg pixmaps between exposes. they exist primarily to improve the visual appearance of the GUI (by avoid tearing and other artifacts of the drawing process). _______________________________________________ gtk-list mailing list gtk-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gtk-list