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