On Jun 10, 2005, at 8:54 AM, Etienne Desautels wrote:
So I guess you are proposing that the part that opens files be threaded so that loading the file off disk does not stall rendering?
This would have to be pretty carefully done in GEM because a lot of the APIs used are not entirely thread safe. Quicktime is pretty hit or miss with threading as is OpenGL. Just opening the file is not really causing the stall, but rather all of the other setup code and buffer management.
With Quicktime on OSX and Windows there might be a way to get around this which involves using a reference movie. The movie would contain a reference to a set of .mov files and once loaded all of the setup would be done once. This might make switching between clips smoother.
This is impossible for your project because there is not enough RAM to hold all the textures needed?
Yes it's impossible. The minimum acceptable size and number of images I have to have is around 70 images of 2048x1024 plus others smaller images. 12MB each (decompression is to slow for large image, slower then reading from disk in my test and least color conversion, JPEG are YUV) x 70 = 840MB. And that's for the real minimum I need.
How many of those images are loaded at once? If you load every single one using pix_image you will be far beyond VRAM and performance will suffer. Uploading images of that size to the GPU takes some time, which might be the cause of the problem.
cgc