Re: GDK_POINTER_MOTION_HINT_MASK has no effect

[Paul Davis <paul linuxaudiosystems com>]

On Thu, 2007-11-29 at 16:24 +0100, Richard Boaz wrote:
> On Nov 29, 2007 1:36 PM, Paul Davis <paul linuxaudiosystems com> 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