On Tue, Aug 17, 2010 at 4:22 PM, Dov Grobgeld <dov.grobg...@gmail.com> wrote:
> The solution won't work if the default expose-event handler returns TRUE. > I would still like to resolve the issues that Paul has with my description > of the code. Paul, why don't you like the fact that I call draw() twice? that's overstating it a little bit. what i was taking issue with is that *unless* draw() has some way to be able to tell that it is being called from an expose event handler (and that would presumably have to be some global variable, since nothing is passed to it as an argument), it is by definition doing the wrong thing *if* it is responsible for all the rendering that occurs in the expose handler. why? because that would imply that it actually renders in both the pre-expose call and the expose-event call, but you should only be rendering (to the window at list) in the expose event call. you asked: How is update() supposed to know what region to invalidate? in your original description, you showed the flow as: # motion event calls update() # update() calls draw() in order to get regions to expose. # update() calls gdk_invalidate_region() based on output from draw # exposure-event callback calls draw() to carry out the drawing for each region so you have logic that knows what regions are affected by the motion event (the above description makes it sound as if that logic is inside draw()). update should have that logic so that it can call gdk_invalidate_region(), and then the expose-event call to draw() should use the event region list to redraw. if your code works, that's fine. i'm just trying to describe to you what i *think* is the right way to do this so that its portable to all backends of GTK and is following the overall drawing model embedded in GTK. --p _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list