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. > 2) Do all drawing in routines separate from your configure handler or > your expose handler. > 3) Call your drawing routine(s) from the configure handler. > 4) Once your drawing routine has completed its task, call > gtk_widget_queue_draw_area() to force the expose event. > 5) Do no drawing in your expose event except to gtk_draw_drawable(), > rendering your background pixmap to the physical display. > 6) Use temporary pixmaps liberally when rendering a "temporary" state > to the screen. (For example, display of cross-hairs and coordinates > when user is simply dragging the mouse (no buttons down) across the > drawing area.) richard, i know you have a lot of experience with GTK, but i believe this is the opposite of the design structure of GTK (and X and also Quartz; not sure about win32). i am not saying that it doesn't work - clearly it does. but the internal design of GTK is assuming that drawing occurs inside expose event handlers, and is set up to make this as efficient and smooth as possible. > Basically, in de-coupling your configure and expose events from actual > drawing, you gain much more power in managing all the requirements of your > drawing area than if you use a single drawing area that is the screen. > Not to mention that drawing directly to the screen is absolutely the > slower of the two options. this is false. _______________________________________________ gtk-list mailing list gtk-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gtk-list
