On Apr 21 KIU Shueng Chuan wrote:
>On 20 Apr 2001, at 19:36, Tim Goetze wrote:
>
>> i set a background pixmap for the drawing_area's window and draw directly
>> to this pixmap. after drawing, synthesize an expose event (or do the blit
>> directly).
>
>hmm... this seems to be exactly what I was doing.
>
>> the X server will now update the window from the contents of the
>> background pixmap in the fastest fashion whenever your window gets an
>> expose event (don't know about how gtk on windows(r)(tm) handles this).
>>
>> after drawing to the pixmap, synthesize an expose event or do the blit
>> yourself.
>
>What I wanted to do in my program was to animate the solving of a
>maze, ie show the wiggling around and backtracking of the path
>taken as it searches for the exit.
>
>For each iteration, I only draw onto the pixmap a mini rectangle,
>the area of which is much much less than the area of the whole
>pixmap itself. (I want to update the screen for each iteration for the
>animation effect)
>
>In other words, if I only update a small piece of the pixmap, is there
>any way to synthesize the expose event to tell it to only update the
>drawingarea from that small piece?
>
>The way I do it currently is to update both the pixmap and the
>drawingarea without synthesizing any expose event for each
>iteration. This is much faster than blitting the whole pixmap for
>each iteration.
then from my understanding there is not much to optimize since you
have to update both the window and the pixmap. synthesizing an expose
event comes down to a lot of additional code being executed; ie the
allocation/filling of the event structure, its routing within gtk and
the decoding of the event. better skip all of this and stick with
doing the blit yourself.
afaik there's no way to automatically synthesize the expose event when
you draw to a drawable in gtk/X anyway (except when you scroll a
drawable with the copy_area family).
though it may feel awkward, in fact this method you (and i too) use is
probably the best you can get if you want flicker-free performance.
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.
if you insist on queuing the redraw without James' updated version,
you might try using idle_add which is in gtk.py 0.6.5 and calls back as
soon as gtk is idle; ie there are no other events to process.
with queue_draw_area however, iirc the behaviour is that queued areas
may be processed together as one bigger expose; but this doesn't seem to
be what you want - the wiggling around in the maze wouldn't look so
wiggly :)
.tim
_______________________________________________
pygtk mailing list [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk
