Hans-Christoph Steiner wrote:
Other people have reported this, but I haven't been able to reproduce it. Please create a bug report in the tracker and submit an example patch. (For whatever reason, no one has done that yet, despite my requests). Then I'll take a look at it.
are you on Linux? the problem probably won't show up on Linux, because of the relationship between Tk and Xlib:
(from the website of the TkGS project http://membres.lycos.fr/fbonnet/Tcl/TkGS/introduction.htm , sadly stalled since 2000)
"So what is the problem with the XLEL? Porting part of the Xlib to new platforms was a good idea in the beginning because it allowed for easier porting of the many existent Tk applications. The counterpart is that one had to use the Xlib graphics model on all platforms to remain portable, and that is the main cause of the XLEL inadequacy: bad performances. Tk is notably slower on platforms other than native X-Window systems. But this lack of performance is not due to the XLEL itself, but to the way it uses the native graphics system. The Xlib uses a fundamentally stateless model, whereas Windows and MacOS use state-based models.
"For example, to draw a shape, a Xlib application calls a drawing primitive such as XDrawRectangle() and passes the drawing parameters as arguments in the form of a Graphics Context (GC), a structure that contains all the drawing parameters such as foreground color or font. On Windows, one has first to create objects such as brushes, pens, fonts, then select these objets that will be used by all the subsequent primitives such as Rectangle(). These objects are selected into a Device Context (DC) that has to be created before any drawing and released after, holding the state in the meantime. These operations are costy and thus should be done once for all before any primitive is called. Besides, since they are available in rather limited resources, one has to be careful to free them all once the drawing operation is complete.
"Since The Xlib uses a stateless model, the XLEL has no choice but to re-create a valid drawing context (eg. a DC on Windows) from its GC values at every drawing operation. That way, costy operations that were intended to be called once before any number of drawing primitives (ie in O(1) time), are called for every primitive (ie in O(n) time), even if the drawing parameters are the same. Thus the relatively bad performances of Windows and MacOS Tk (even on the same hardware). A solution would be to use caching schemes to avoid useless re-creation of drawing structures. Leo Schubert's speedpatch for Tk 8.0 uses this kind of technique (it stores the internal GDI objects into the GC structure). Although the results are impressive in term of performances, these techniques have several drawbacks: ..."