Tim Goetze <[EMAIL PROTECTED]> wrote:
>regarding queue_draw_area, i think it doesn't really matter if you
>queue the redraw for later or do it right after the pixmap has been
>drawn to; drawing immediately has the advantage of reducing complexity
>in your program but that may be a matter of personal preference.
>
Well, it's really a matter of *redraw complexity* and performance. If I
have to force a complicated redraw (a VLSI layout editor, to take a "random"
example) on reconfigure/resize, I certainly do not want to call a full draw
and block all response. I will have to draw the thing in chunks while
taking and handling events in between. I can explictly take and dispatch
events myself during a redraw (probably the most efficient, but sometimes
hard to make sure you dispatch *all* events correctly), or I can place the
redrawing method in an idle loop (often very slow and hard to predict how
your idle handler affects response), or I can absorb the whopping big expose
event and send it a bunch of little ones (less control over how the events
come in and possible blocking of other events in the pipeline). Note that
these methods are in order of programming complexity from hard -> easy but
in order of control and flexibility from very -> little.
In small, fast programs which method you choose isn't important, but the
choice becomes more important as the reconfigure/resize complexity rises.
I haven't said anything about expose complexity because I always use a
backing pixmap and my expose complexity is constant.
-a
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com
_______________________________________________
pygtk mailing list [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk
