[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