[PD] Gem - CPU usage 98%

[IOhannes m zmoelnig]

klaas de Baas wrote:
> Thanks for your answers.
> 
> It is probably true that I could make a more efficient patch in which my 
> usb webcam functions as a motion detector. (I use pix_movement followed 
> by pix_blob to check for movement, and there might be a way of using 
> just one pix object instead. I just didn't figure that out yet. 
> Suggestions?) ((Note that I am not texturing the gemlist of the 
> webcaminput into the gemwin. I just want it to supply me with 1 or 0 
> each cycle))

just to make sure: you only detect whether there is some movement in the 
image or not? then go with the smallest possible pix-size
make sure to do the blob-tracking only on 1 channel;
don't do rgb->grey conversion within blob; if the capture card drivers 
support output as greyscale you might want to try that;
converting the image to greyscale in gem _might_ be a penalty (but as 
well not; try it)
if the camera can output greyscale (even if the driver supplies them as 
rgb(a)) use this and let the pix_blob just work on any one of the channels.

> 
> However, my main problem of cpu overload lies with pix_movie / pix_film 
> (i.e. I experience the same when I just make a simple play movie patch). 
> The cpu-load commences when I create a Gem window of course. And that is 
> why I was puzzled, I thought that creating a texture on a rectangle in a 
> gemwin was handled by the graphics card, if powerful enough.
> 

well, as soon as the pixeldata is on the gfx-card's ram you are done and 
the rest will be handled on the gpu.
however, displaying a movie means decoding it, which is costy, depending 
on the codec (the better the compression the more cpu you will need; the 
  worse the compression the more hd-access you need)

downloading the pixels onto the gfx-cards memory might also take some 
time. [pix_movie] should perform better here.

mfg.asdr
IOhannes