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)