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@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