pix_movie performance

Mark Danks mdanks at Stormfront.com
Wed Apr 12 18:17:46 CEST 2000


  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 at stormfront.com
= http://www.danks.org/mark
============================
  
-----Original Message-----
From: Thomas Loop [mailto:thomas.loop at unibas.ch]
Sent: Wednesday, April 12, 2000 8:59 AM
To: pd-list at 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.
 

 



More information about the Pd-list mailing list