[GEM-dev] Re: [PD] GEM Linux and video codecs

[chris clepper]

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