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

[Adrian Stutz]

2009/5/7 Michael Guntsche <mike at it-loops.com>:
>
> On May 7, 2009, at 18:59, Michael Guntsche wrote:
>
>> I was too early with my feedback. Further testing with your new patch
>> (no_nsapp) showed that the issue is still there it just takes a longer time
>> to show.
>> The older (check_events) patch has worked without a problem so far. I
>> think the reason for this is that there are still Cocoa methods being called
>> even with a shared_buffer hence we end up as an NSApplication. I applied the
>> flip_page and check_events patch to my current source and will do some
>> further testing, I do think that I won't see this problem with it though.
>
> Ok once again I was too early to say that everything was ok. While I no
> longer got the (not responding) message in the activity window ObjectAlloc
> told me that this change introduced a leak. After seeing this I wondered
> again why the events are not taken care of automatically in the first place.
> So I read up on it and found out the following.
> Normally with an NSApplication the "run" method is called as the last step.
> One part the run-method is doing is to process all incoming events. Here the
> run method is NOT called so we have to do this ourself. Attached patch is
> the latest attempt to fix this.
> It is pretty simple, we just implement a poor mans run method by forwarding
> ALL events to the NSApp. With this change I neither get the error NOR
> leaking mallocs. The output of ObjectAlloc shows that there might be other
> leaks in there as well, but I will try to fix them in a next step.

What's "a longer time"?
I've just tested with no NSApplication and a 30 minutes movie file and
the MPlayer process is never marked as inactive. How do you start your
MPlayer process and on what system are you on?

Also, when I checked, there were no events actually sent to MPlayer.
The nextEvent message always returns nil and nothing can actually ever
be forwarded to the NSApp object. So I think the memory leak doesn't
have anything to do with events not being processed (there aren't any)
but with a call to a core foundation class without a autorelease pool
in place that gets emptied in good time, as I've mentioned before.

I will take a closer look when I get time this weekend.

Greetings
Adrian