[PD] in which context is GEM slow ?

cgc cgc at humboldtblvd.com
Thu Feb 19 05:05:40 CET 2004

On Feb 18, 2004, at 7:43 PM, julien.breval at tremplin-utc.net wrote:
> For example, when I draw only 4 white mouse-movable squares over a 
> black
> background, in a 300x300 window, the performances are good (in full 
> screen
> too). But if I replace the background by a small PNG image (about 12 
> ko), GEM
> slows the program a lot (there are cuts in the audio stream). This 
> happens
> under Windows XP with a recent computer and a usual graphic card. Is 
> it normal ?

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?  And what does your patch look like?  
pix_image with pix_texture will only texture the images once after they 
are loaded so there would not be any constant performance drain.  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.  Some relatively 
minor looking pd GUI elements can take a surprising amount of CPU.

> In which cases does GEM become slow like this ? Should I rather use 
> GEM under
> Linux ? Or, maybe GEM is rather adapted to Open GL than image or video 
> matrix
> processing ?

If you are only doing four squares with small images on them and your 
hardware is fairly recent then there is something else wrong that 
moving to another OS would only fix by accident.  I can only throw out 
guesses without knowing more.


> Thanks for your help
> -- 
> _______________________________________________
> PD-list mailing list
> PD-list at iem.at
> http://iem.at/cgi-bin/mailman/listinfo/pd-list

More information about the Pd-list mailing list