[PD] in which context is GEM slow ?
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
> background, in a 300x300 window, the performances are good (in full
> 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
> 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
> 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
More information about the Pd-list