[PD] in which context is GEM slow ?

julien.breval at tremplin-utc.net julien.breval at tremplin-utc.net
Thu Feb 19 15:58:41 CET 2004


There is a HUGE speed difference depending if you use [pix_texture] or 
[pix_draw]

that was the problem, sorry for this 

by the way, thanks to the [pix_texture2] object, you can use any image size



> > 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