[PD] pd-extended 0.40.3 ui performance

[Damian Stewart]

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: ..."



-- 
damian stewart | +31 6 5902 5782 |  damian at frey.co.nz
frey | live art with machines | http://www.frey.co.nz