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