68 lines
2.7 KiB
Plaintext
68 lines
2.7 KiB
Plaintext
From: fredrik at pythonware.com (Fredrik Lundh)
|
|
Date: Tue, 20 Apr 1999 13:48:50 GMT
|
|
Subject: Tkinter performance
|
|
References: <371B4B39.8B78BC7A@foreman.ac.rwth-aachen.de> <19990420083759.A133486@vislab.epa.gov>
|
|
Message-ID: <020701be8b34$8960b810$f29b12c2@pythonware.com>
|
|
Content-Length: 2419
|
|
X-UID: 814
|
|
|
|
Randall Hopper <aa8vb at vislab.epa.gov> wrote:
|
|
> Note that the canvas seems to have respectable optimizations in place so
|
|
> the less that is visible (e.g. the more you're zoomed in, the faster
|
|
> redraws get. Also if only a partial area needs redrawn, it redraws it
|
|
> fairly quickly relative to the full-expose frame rate. It's obvious
|
|
> there's some optimization going on when you load to make drawing faster.
|
|
|
|
some background: the canvas widget uses a straight-forward
|
|
"damage/repair" model. changes to the canvas, and external
|
|
events such as Expose, all update a single "dirty rectangle".
|
|
they also register an idle task (after_idle) which redraws the
|
|
canvas when you get back to the main loop.
|
|
|
|
when it's time to redraw the canvas, the widget starts by
|
|
allocating a pixmap (on X windows, this is an image memory
|
|
stored on the display) with the same size as the dirty rectangle.
|
|
it then loops over the canvas items, and redraws *all* items
|
|
whose bounding box touch the dirty rectangle (this means
|
|
that diagonal lines may be redrawn also if they don't actually
|
|
cover the rectangle, but this is usually no big deal). finally,
|
|
the widget copies the pixmap to the display (this last step is
|
|
a very fast operation on all modern hardware), and releases
|
|
the pixmap.
|
|
|
|
a few additional notes:
|
|
|
|
-- most Tk widgets use double-buffering to prevent flicker
|
|
(this includes simple widgets like buttons and labels). there's
|
|
no way to change this in current version of Tk.
|
|
|
|
-- most Tk widgets also use delayed drawing. that is, they
|
|
respond to modifications and external events by scheduling
|
|
an idle task, not by updating the screen directly. there's
|
|
no way to change this in current versions of Tk.
|
|
|
|
-- the repeated allocation of pixmaps can seriously affect
|
|
performance if you're animating stuff in a maximized window
|
|
on a large truecolor display... (we all have 1800x1440 24-bit
|
|
displays, don't we?)
|
|
|
|
-- since the canvas uses a *single* dirty rectangle, you can
|
|
get better performance in some situations by forcing updates.
|
|
for example, if you're changing things in different parts of the
|
|
canvas without returning to the main loop, adding explicit
|
|
calls to update_idletasks() allows the canvas to update a
|
|
few small rectangles, instead of a large one with many more
|
|
objects.
|
|
|
|
-- the text widget is a bit smarter than the canvas...
|
|
|
|
-- guess I should mention uiToolkit here, but I'll leave that
|
|
for another day...
|
|
|
|
</F>
|
|
|
|
|
|
|
|
|
|
|