In Gtk3, "draw" is used instead of the expose signal and gives you a cairo context (at least for external api users). This document may also answer some of the questions: http://developer.gnome.org/gtk3/3.4/chap-drawing-model.html
I wouldn't expect being able to use the cairo context you are passed after you give control back to the system. As John mentioned, use event queuing (gtk_widget_queue_draw or gtk_widget_queue_draw_area) after your data model (or offscreen image) is changed. This will essentially cause your draw to be called. You may be able to force an immediate redraw after you queue a draw event, but I doubt this would be necessarily, see: http://developer.gnome.org/gtk3/3.4/gtk3-General.html#gtk-events-pending gtk_widget_queue_draw(widget); while (gtk_events_pending ()) gtk_main_iteration (); Try using cairo->get_clip to retrieve the current clipping area of the context in your draw callback, but I'm unsure about this. If you are doing a lot of user interaction with annotations and what not, another route might be to look into using the clutter api along with gtk: http://www.clutter-project.org I've recently started porting my app from being pure gtk/cairo based with lots of viewport interaction to using clutter and I've been able to delete a significant amount of code. -Simon On Fri, Apr 6, 2012 at 8:14 PM, <jcup...@gmail.com> wrote: > Hi Roger, > > You should do all drawing in the expose handler and nowhere else. > Don't do any direct drawing in your data hander, instead update your > model and queue an expose event. > > On 7 April 2012 02:16, Roger Davis <r...@soest.hawaii.edu> wrote: > > presumably this includes the GtkDrawingArea widget as well. If there is > > documentation on exactly how this double-buffering works with regard to > > GtkDrawingArea I would be greatly interested in seeing it to figure out > if > > Here's how it works in gtk2, I think this bit hasn't changed much for gtk3: > > * an expose event comes in from X11 > * it gets added to the set of pending expose events on your drawing > area -- gtk computes the minimal set of non-overlapping damage > rectangles > * when gtk feels the time is right to update your window, it allocates > a backing pixmap just large enough to hold all damage > * the backing pixmap is filled with the background colour for your widget > * the expose handler is triggered, passing in the backing pixmap as the > drawable > * your expose handler draws to that --- you can fill the whole thing, > or you can loop over the (possibly smaller) list of damage rects that > make it up > * gtk clips against the damage outline and writes the new pixels to the > display > * the temporary pixmap is deleted > > As a former xlib programmer I was slightly horrified when I head about > all this, but it actually works pretty well on non-ancient machines. > My program disables the double buffering and does its own thing for my > main data display, since I don't want the "clear to background" > behaviour, but I use it everywhere else. > > The discipline of only drawing in the expose handler is also helpful. > It forces you to decouple drawing from updating which will make your > performance degrade much more gracefully under load. Instead of > suddenly getting lag when you run out of cycles, you'll just see a > drop in the frame rate. > > John > _______________________________________________ > gtk-app-devel-list mailing list > gtk-app-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list > _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
