Thanks Chris,
Only the 3D OpenGL parts of GEM (Geos, Manips, Particles) are accelerated by the GPU. You can do image processing using the GPU and objects like fragment_program though. Any pix_ object is handled by the CPU.
My Gemlist ends in a rectangle, which is a Geo, as far as I understand. So I went and put your statement to the test, with a spigot before the pix-film, and another one before the rectangle. CPU-load did not drop significantly when switching off the rectangle, but it did when switching off gemhead->pix-film. So I guess I was looking in the wrong place, and it is more of a codec decoding load as IOhannes suggests in his later post.
I'm not sure what you refer to with "fragment_program". My guess is it is from another library (i.e. not from Gem)?
GEM uses old VideoForWindows code to play AVI files which is slower than DirectShow. Mediaplayer uses a full DirectShow path and there are a number of efficient paths when you can do that. GEM has a full OpenGL rendering engine so we cannot use things like the DirectShow hardware mixer and scaler, and once you get off the narrow predetermined DS path things slow down qite a bit. There are plans to use Directshow for loading AVI files in the future, but it will still not be as efficient as MediaPlayer (hopefully it will be close though).
cgc
There's quite a few things I understand now. After using my patch for a project the next two months, I am planning to switch to Linux from Windows. How does that OS environment compare with regards to Gem's handling of high resolution 2d video?
Ciao Klaas