[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