[PD] in which context is GEM slow ?

julien.breval at tremplin-utc.net julien.breval at tremplin-utc.net
Thu Feb 19 15:17:38 CET 2004

> One problem is that GEM on windows only handles power-of-two textures 
> (64, 256, 512, etc).  So if you have a 300x300 image that becomes 
> 512x512 in OpenGL on windows.  With small static images you should not 
> have any sort of performance issue even on very old hardware.  What 
> type of hardware are you using?  

Intel 82845G Graphics Controller (internal video device), with a recent PC 
(Pentium 4 2.4 GHz, RAM = 512 Mo)

> And what does your patch look like?  

There is a constant picture as a background ; above this picture there are 4 
small GL squares that repreasent four (x,y) positions ; you can move these 
squares with the mouse

I'm sorry I didn't know that pictures sould have a size of a power-of-2 ; in 
this case, I would like to use 512 x 512 pictures  

> Also, 
> dropouts in the audio are pretty much a part of pd right now and it 
> might not even be the GL stuff causing you problems. 

not in that precise case, because without the new GEM "user interface" there is 
no problem ; moreover, when I replace the image by a constant background 
colour, it works very well

Maybe I should try with power-of-2 images or smaller images 

> Some relatively 
> minor looking pd GUI elements can take a surprising amount of CPU.

If you are talking about the graphic [bang]or other Tcl/Tk graphics (Array, 
etc), I agree, but there is no stuff like this either in my patch (at least as 
few as possible, and hidden in subpatches)  

More information about the Pd-list mailing list