[MPlayer-dev-eng] [PATCH] vo_macosx: process events with shared_buffer (and patch roundup)

[Adrian Stutz]

On Mon, May 4, 2009 at 8:37 PM, Michael Guntsche <mike at it-loops.com> wrote:

> Thanks for looking into this. I do not think we need an autorelease pool in
> this special case though,
> since we are not doing an initwith or similar at all. NSApp is already
> there and we are just using it in this case.
> Also keep in mind that in your implementation right now the autorelease
> pool is created and deleted in the checkEvents function, while NSApp exists
> as long as the mplayer NSTask is running.
> So I really do not think that we are leaking anything here without an
> autorelease pool.
>

There is an autorelease pool in place, created at launch and emptied only
when closing. So autorelased objects are actually properly released but only
when MPlayer closes. This allows autoreleased objects to accumulate while
MPlayer is running, which I think also qualifies to be called a leak, even
if the objects are properly released at the very end.

In case of the flip_page NSConnection, the accumulated autoreleased objects
amount to 15MB after just 5 minutes. In that case the call is also to an
existing object but Cocoa is creating and autoreleasing objects in the
background. To see if the specific call in check_events is causing such
allocations would need to be tested and cannot be assumed, since the actual
allocations are hidden in the Coaoca implementation. It's also not clear if
later changes to OSX could silently introduce such a leak at a later time.

Usually a Cocoa run loop is in place, which then takes care of periodically
releasing autoreleased objects. But when MPlayer is used with shared_buffer,
no Cocoa run loop is in place and autoreleased objects just linger around.
Since it's recommended to create and release autorelease pools in the same
context, the only place the put them is directly in the flip_page and
check_events functions.

--

Though, on second thought, do we actually need the NSApp object in case
MPlayer is used only with shared_buffer as a background application? Other
unix background applications don't show up as unresponsive in OSX even if
they don't check the Cocoa event queue. If we remove the NSApplicationLoad
call for use with the shared_buffer option, then there's no need to check
the event queue either. As far I could gather, NSApp is only needed for
applications the user can actually interact with (has windows, receives
events) or that has a Cocoa run loop. Both cases don't apply to MPlayer used
with shared_buffer and testing showed no problems.

Attached patch changes vo_corevideo so that the NSApp is only initialized
without shared_buffer. This also makes checking for events unnecessary when
using shared_buffer.

Greetings
Adrian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vo_corevideo_no_nsapp.patch
Type: text/x-diff
Size: 979 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20090504/e17415e4/attachment.patch>