[GEM-dev] pix_video again

james tittle tigital at mac.com
Thu May 11 19:31:58 CEST 2006


On May 11, 2006, at 1:20 PM, chris clepper wrote:
> I'm not sure if any of that matters.  I haven't seen any problems with
> the pix_film object and my testing is up to several million files and
> many thousands of hours.
>
> At this point problems are likely to be Quicktime issues related to
> specific codecs.

...yeh, closer inspection shows that prepareTexture() is only used  
pix_movie-derivatives, or else is an empty function...and of course I  
mis-read the "#ifndef", so I was thinking we were double-requesting  
buffers...however, the cache stuff is real, and a simple fix, but not  
probably germaine to the problem here...

...I'll try to set up some testing overnight here, and see if I can  
see any of this problem...

sigh,
jamie

> On 5/11/06, james tittle <tigital at mac.com> wrote:
>> ...hmm, I'm looking at [pix_film] and whaddaya know?  There seems to
>> be all kinds of stuff going weird with createBuffer(), deleteBuffer
>> (), and prepareTexture() :-(  First off, pix_film::openMess() has:
>>
>> #ifndef __APPLE__
>>    createBuffer();
>>    prepareTexture();
>> #endif
>>
>> ...this may be a relic/hack from waaaay back?
>>
>> ...but this occurs AFTER pix_film::openMess() calls realOpen(), which
>> is in pix_filmDarwin.cpp...this may be significant because in
>> pix_filmDarwin::realOpen() we call the same things (or not) based on
>> the value of m_colorspace (BGRA or other)...
>>
>> ...also, pix_film::createBuffer() will never cache the buffer because
>> oldx and oldy aren't member variables AND they're always set to 0, so
>> we always hit this:
>>
>> if (neededXSize != oldx || neededYSize != oldy)
>> {
>> deleteBuffer();
>> ...
>> }
>>
>> ...um, and that's as far as I've gotten:  I'll give some of these
>> ideas a test, but won't have much time until, uh, later...
>>
>> jamie
>>





More information about the GEM-dev mailing list