openframeworks/openFrameworks — pull request #913 by gameoverhack (2012-02-11 01:11:44+00:00)
Title: Bugfix of quicktime player (updated)

Apologies it turns out my last fix to closeMovie was not the best approach: https://github.com/openframeworks/openFrameworks/pull/887

Adding width = height = 0 in closeMovie forces the QuicktimePlayer to reallocate pixels and MemGWorld every time you have closed a movie in an instance...but after more extensive testing on Mac and PC it would seem that a better approach is to not clearMemory() in the closeMovie call, but only in the dtor.

This is for two reasons:

!) we don't clear the gWorld pixels and we don't dispose of the MemGworld in the closeMovie call so it doesn't make sense to clear our pixels
2) if you are rapidly (ie., in a thread) opening and closing movies of the same width and height as fast as possible it turns out it's best not to try to dispose and reallocate the memGworld and gWorld pixels -> this is possibly because we are not deleting the gWorld pixels (the crash is a malloc error when new'ing the gWorld pixels)

Using this method gives the fastest results when loading/unloading movies of the same size.

If we're not happy with leaving memory allocated after a call to closeMovie we could try another approach which is to move the calls in the dtor into the closeMovie call...

But it seems to me that there is no harm in leaving the pixels, gWorld pixels and MemGworld allocated in an instance...the smart pointer will delete the pixels if we stop using the instance and if the user is using a pointer then they will delete it with the same result...