On Thu, 2007-11-29 at 16:24 +0100, Richard Boaz wrote: > On Nov 29, 2007 1:36 PM, Paul Davis <paul@xxxxxxxxxxxxxxxxxxxxx> wrote: > > On Thu, 2007-11-29 at 09:51 +0100, Richard Boaz wrote: > > This is the paradigm I use in all my drawing apps that has served me > well: > > > > 1) Do all drawing to one or more background pixmaps. > > GTK already does this for you now. All widgets are double buffered > unless you explicitly request otherwise. So you are currently drawing > into your bg pixmap, than GTK will copy it into another bg pixmap and > then finally render it to the screen. > > Well, this confuses me a bit. Help me understand? [ ... code .... ] > I assume the double-buffering occurs at least with each call to > gdk_draw_line(), but when is this double-buffer (that you the programmer > have no access to, I assume?) actually rendered to the screen? After each > call, or only once the expose handler has exited? > > If this physical event occurs only after the expose handler has exited, > then kudos to the GTK+ designers and developers, this is very good. And > you are correct, my method employs an extra bg pixmap that is, in this > simple case, unnecessary, though in any case, not expensive. that is precisely what happens. drawing calls made during an expose event handler are "redirected" into a bg pixmap; at the end of the expose handler, the relevant parts of the bg pixmap are flushed to the screen. > And this particular > case is wholly not addressed in code sample 1; there, you must redraw the > entire screen even if only 4 pixels in the lower right corner require a > re-draw. As I said before, using the GdkEvent* info to be efficient in > redrawing only what's required is impossible, and if not, a complete waste > of programming time and resources. no, there is never any need to do this. expose events always contain information on the region (a collection of 1 or more non-overlapping rectangles) to redraw. this is based either on information from the underlying window system or whatever was passed to gdk_window_invalidate_rect() and its cousins. the only limitation is that GDK generally "tiles" a drawable with rects no smaller than a given size, so if there were really just 4 pixels to redraw, you'd like end up redrawing 32 or 16 or some such number. > As I also stated, a particular method to choose comes down to > requirements. I now have an application that has more than 30 drawing > areas (across several tabs/screens), each requiring different routines to > make their picture. Doing all my drawing in an expose handler means that > I must define a different expose handler for each drawing area. But this > goes against another principle I have come to embrace, define as few > callbacks as possible for widgets to use; I have a single configure and > expose handler for all drawing areas, a single callback for all mouse > events, drag events, radio button groups, etc. Why? This minimizes the > number of routines that are required to exist and be defined, and for me, > using nothing more than gedit as my editor, infinitely makes the chore of > coding much easier to manage. i didn't suggest unique code per expose handler. i said that all drawing should be done in *an* expose handler. your examples look perfectly "sensible" and "correct" to me. you're doing precisely what i was trying to convey as far as callbacks, except that: (a) you're using bg pixmaps that are unnecessary (b) i believe that configure events will be followed by the necessary expose events, so your queue_draw() calls in the configure handler are not required (they won't hurt though) --p _______________________________________________ gtk-list mailing list gtk-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gtk-list
