I am not certain why you are having performance problems. I have used 5 pix_movie's on a 450PII with a TNT1 on WinNT with a minimal hit. Memory really isn't the issue, because the data is just streamed in from the drive. You could convert the movie to a series of images and use pix_multiimage to cycle through them. This uses a different mechanism for dealing with the texture data.

As far as the OpenGL performance, just make sure that you have the newest drivers from nVidia's web site. If you are just using the ones from the CD, then they are slow and buggy. You do not need to copy any dll's around. You should have screaming performance with the GeForce card. To make sure that you have the OpenGL drivers installed correctly, send a print message to a gemwin. If the vendor reads Microsoft or the renderer is OpenGL generic (or software something) then you are doing software OpenGL rendering...which is where your performance problems are.

As far as pix processing, etc, pix_movie automatically uploads the texture to the video card, so you can't do things like pix_2grey or pix_threshold. However, you can set the color and alpha with a color object.

If you have an example patch with data, then I can test it out on my machine and see what is going on.

Later, Mark

============================ = mdanks@stormfront.com = http://www.danks.org/mark ============================

-----Original Message----- From: Thomas Loop [mailto:thomas.loop@unibas.ch] Sent: Wednesday, April 12, 2000 8:59 AM To: pd-list@iem.mhsg.ac.at Subject: pix_movie performance

Hi.

We are trying to set up a patch for non-linear control of various video snippets via midi. (NN, please hold your breath - we can't afford a G4 running Nato ;-) Machine is an Athlon 700, 128MB PC100 and an AGPx2 Asus Geforce with 32MB DDR RAM. Running Win98/Win2k. The patch is based on pix_movie and the size of the AVIs is under 5MB and with 160-320 pixels width. The videos are mapped on squares.

Performance is quite disappointing. One video runs quite smoothly. By adding a second one the framerate already drops into very ugly ranges. Any traps we're running into with this concept? What are the performance limiters for actions like this? There's nothing else running and memory should be enough for at least 5-10 AVIs... Can't imagine that the AGP already chokes on stuff like this, but maybe I'm wrong.

Also we have the feeling that OpenGL performance is a bit low on our machine, even with simple objects. I read something in the FAQ about copying the opengl32.dll into the PD directory to let GEM know about the driver. What exactly is GEM/PD looking for? The Nvidia OpenGL-driver has a different name. Should we copy it anyway?

Is there any documentation available for the pix_movie object? Alpha blending, chroma-keying?

Any helpful input would be greatly appreciated.

            .loop.