On Feb 17, 2009, at 12:52 AM, Markus Guhe wrote:
Follow up: I filed a bug report on this issue, number 6593625.
Thank you for the bug and especially for the easily reproducible test
case. Very much appreciated.
I stole the bug out of the inbound queue and had a look.
Basically, when the media file is dropped into the view, it is
creating a QTMovieView that sits on top of and moves with the
underlying NSTextAttachmentCell.
When the attachment cell goes away, the movie view is not removed from
the view hierarchy.
Since the movie view is still visible within the window, the next step
is to figure out what is keeping it around (beyond being in the view
hierarchy). That'll answer the question of whether simply removing it
from the view hierarchy -- working around the bug -- is enough to make
it go away.
I added a little bit of code to your Controller and a Dump button in
the UI to trigger it:
static int spaces = 0;
- (void) dumpViewHierarchy: (NSView *) aView;
{
int i;
for(i=0; i<spaces; i++) fprintf(stdout, " ");
fprintf(stdout, "%s: %p\n", object_getClassName(aView), aView);
spaces = spaces + 1;
for(NSView *subview in [aView subviews]) {
[self dumpViewHierarchy: subview];
}
spaces = spaces - 1;
}
- (IBAction)findMovieView:(id)sender;
{
[self dumpViewHierarchy: [[txtView window] contentView]];
}
Then:
(before an audio file is dragged in)
NSView: 0x181e380
NSScrollView: 0x181e4c0
NSClipView: 0x18284f0
NSTextView: 0x18123c0
NSScroller: 0x18296e0
NSScroller: 0x1829820
NSButton: 0x1829960
NSButton: 0x181f9d0
NSButton: 0x18295c0
(after an audio file is dragged in)
NSView: 0x181e380
NSScrollView: 0x181e4c0
NSClipView: 0x18284f0
NSTextView: 0x18123c0
QTMovieView: 0x186dee0
QTMovieViewSurfaceRendererView: 0x1865bf0
QTMovieControllerView: 0x1876520
NSScroller: 0x18296e0
NSScroller: 0x1829820
NSButton: 0x1829960
NSButton: 0x181f9d0
NSButton: 0x18295c0
(after clicking the "set empty string" button)
NSView: 0x181e380
NSScrollView: 0x181e4c0
NSClipView: 0x18284f0
NSTextView: 0x18123c0
QTMovieView: 0x186dee0
QTMovieViewSurfaceRendererView: 0x1865bf0
QTMovieControllerView: 0x1876520
NSScroller: 0x18296e0
NSScroller: 0x1829820
NSButton: 0x1829960
NSButton: 0x181f9d0
NSButton: 0x18295c0
OK -- sure enough... the QTMovieView is not being removed from the
view hierarchy. But what else might still be hanging on to it besides
the view?
Using gdb (there is a bug in Instrument's ObjectAlloc that prevented
me from using it:
gdb /tmp/bbum-products/Debug/NSTextViewVideo.app/Contents/MacOS/
NSTextViewVideo
(gdb) set env MallocStackLoggingNoCompact=1
(gdb) r
Then:
(gdb) info gc-roots 0x186dee0
Which, in between some warning noise and other stuff, shows that the
QTMovieView is only really referred to as a first responder and as a
part of the view hierarchy.
Thus, what happens if we just rip it out?
Well... that works, but the movie view isn't actually gone if you poke
about in memory.
It appears that the attachment cell helper is hanging on to it;
somewhere in the bowels of the layout manager. To fully workaround
the issue, you'd probably need to muck about with the layout manager's
APIs to reset it.
b.bum
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
