[GEM-dev] pix_video again

[james tittle]

hey all,

On May 11, 2006, at 9:05 AM, Erich Berger wrote:
> of course pix_film !
> - she is using osx on a minimac with the
> version u have commited a bug fix (for pix_fim)
> on 8th of november.
>
> On Thu, 11 May 2006, chris clepper wrote:
>
>> I think you mean pix_film or pix_movie.  What OS and GEM version?
>>
>> On 5/11/06, Erich Berger <eb at randomseed.org> wrote:
>>> hi,
>>> i have some question regarding memory management and pix_video.
>>> a friend of mine is using it for playing in some certain order  
>>> about 70
>>> small clips for an installation. she had it test running the  
>>> whole night
>>> and reported that is was becoming extremly slow when she had a  
>>> look at it
>>> in the morning. i had no possibility to check the stuff but i  
>>> guess that
>>> it is because the memory got full by constantly loading the clips.
>>> now the questions:
>>> when pix_video is loading another clip, is it freeing the memory  
>>> which
>>> took the clip played before or does it stay in the memory ?
>>> when the same clip is played again after playing another one is  
>>> it loaded
>>> again into the memory or is the one already loaded before used  
>>> again ?
>>> is there a method to clear the memory taken over by all this loaded
>>> films without restarting pd ?

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