Re: problems understanding gtk3/gdk/cairo interaction

[Simon Feltman <s feltman gmail com>]

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, <jcupitt 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 <rbd 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