Re: problems understanding gtk3/gdk/cairo interaction

[Roger Davis <rbd soest hawaii edu>]

Hi John,

Thanks for your thoughts as always. I think there may be some significant 
differences between gtk2 and gtk3 on these points, although this guess is 
based almost exclusively on reading documentation at this point as opposed 
to actual experience, of which I have about zero. Given the magnitude of 
the project in front of me I have decided to start right in on gtk3 and 
save myself yet another porting job, so I'm not paying much attention to 
gtk2.

I have noticed, however, that there seems to be a lot less mention of 
expose event processing in gtk3 vs. gtk2, they seem to be trying to 
abstract further and further away from X11, or at least that's my highly 
uninformed guess. That seems to be particularly true with regard to the 
implementation of the GtkDrawingArea. In gtk2 it appears that you register 
an expose_event handler, and when that's called you are passed a 
GdkEventExpose which contains a GdkRectangle and a GdkRegion, i.e., you 
get some clues as to the extent of the exposed region. In gtk3 it's quite 
different -- there is no expose_event handler, rather you get only a draw 
handler whose only argument of interest is a cairo_t context pointer. My 
reading of the documentation does not lead me to believe there is any way 
to actually figure out the extent of the expose rectangle from this 
argument, although there are comments in the documentation that indicate 
that GDK somehow clips all drawing to the exposed area inside this draw 
handler. I suppose what I need to do here is figure out my own damage 
extent and mail off a gtk_widget_queue_draw_area(), then call the cairo 
equivalent of XCopyRectangle() using the entire off-screen cairo surface 
as my source rectangle and hope for the best in terms of clipping 
efficiency.

I need to do some experimentation here and just see what happens, of 
course, but I have to say that I'm more than faintly horrified by this -- 
I expect that some things I do with regard to rubberband lines which 
potentially stretch diagonally between opposite corners of the window are 
going to have absolutely ghastly performance because I need, for every 
single MotionNotify event emitted by a user's mouse drag (or maybe not 
quite that much if I use the motion hints feature), to redraw an 
entire megapixel of imagery via one large exposure rectangle or build a 
very large list of tiny exposure rectangles spanning such a 
corner-to-corner line which I somehow calculate myself, which strikes me 
as a non-trivial task from a programming standpoint. Ahh, the joys of 
discovery.

Thanks for your suggestions!

Roger