On Jun 29, 2008, at 11:56 AM, Damian Stewart wrote:
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:
I use Ubuntu, Debian, and Mac OS X. TkGS isn't really relevant
anymore. With Tcl/Tk 8.5 has big improvements on Mac OS X, I believe
they completed the port from the old Carbon graphics to the current
CoreGraphics.
Thanks for the bug report!
.hc
(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: ..."-- damian stewart | +31 6 5902 5782 | damian@frey.co.nz frey | live art with machines | http://www.frey.co.nz
Access to computers should be unlimited and total. - the hacker ethic