[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