[PD] pd-extended 0.40.3 ui performance

[Hans-Christoph Steiner]

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 at frey.co.nz
> frey | live art with machines | http://www.frey.co.nz


------------------------------------------------------------------------ 
----

Access to computers should be unlimited and total.  - the hacker ethic