gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NSWindow & NSGraphicsContext issue


From: Gregory John Casamento
Subject: Re: NSWindow & NSGraphicsContext issue
Date: Tue, 20 May 2008 04:31:22 -0700 (PDT)

I'll try that one.   I had downloaded another version, but I think it's the 
same.

 Gregory Casamento -- Principal Consultant - OLC, Inc 
# GNUstep Chief Maintainer


----- Original Message ----
From: Fred Kiefer <address@hidden>
To: Gregory John Casamento <address@hidden>
Cc: GNUstep Developer <address@hidden>
Sent: Tuesday, May 20, 2008 4:34:53 AM
Subject: Re: NSWindow & NSGraphicsContext issue

Strange, I get the log message as soon as I open an image from the 
ToyViewer open menu entry.

The ToyViewer version I am using is this one:
http://www.sonappart.net/TV.tar.bz2

Hope this helps
Fred

Gregory John Casamento wrote:
> I've tried to recreate this issue.  I am not seeing the NSLog that was added 
> come up once during my tests either when running the application (ToyViewer) 
> or any other apps.
> 
> I'm continuuing to look into it.   I'm going to open a bug on this so that 
> the progress can be tracked there.
> 
> GC
> 
>  Gregory Casamento -- Principal Consultant - OLC, Inc 
> # GNUstep Chief Maintainer
> 
> 
> ----- Original Message ----
> From: Gregory John Casamento <address@hidden>
> To: Fred Kiefer <address@hidden>; GNUstep Developer <address@hidden>
> Sent: Monday, May 19, 2008 4:34:49 PM
> Subject: Re: NSWindow & NSGraphicsContext issue
> 
> Fred,
> 
> I will take a look at this as soon as possible.    The solution should allow 
> existing gorm files to be handled properly as well as correct the problem 
> going forward.
> 
> GJC
> 
> Gregory Casamento -- Principal Consultant - OLC, Inc 
> # GNUstep Chief Maintainer
> 
> 
> ----- Original Message ----
> From: Fred Kiefer <address@hidden>
> To: GNUstep Developer <address@hidden>
> Sent: Sunday, May 18, 2008 7:26:06 PM
> Subject: Re: NSWindow & NSGraphicsContext issue
> 
> I was able to resolve most of the problems I listed below by not using 
> autorelease objects.
> 
> There still is one issue and it is an important one. When creating an 
> NSWindow from a Gorm file the initialization is called twice. This will 
> result in two backend objects being created for the window and one of 
> them would leak and the window map would stay in an inconsistent state, 
> after the window is freed. I was able to hack around this, by adding a 
> check for an already existing _windowNum into 
> initWithContentRect:styleMask:backing:defer:screen:. This only prevents 
> part of the problem and a real fix would be not to have an NSWindow (or 
> a subclass) in a Gorm file at all. For NIB files we already us 
> NSWindowTemplate instead of GSWindowTemplate and this prevents the problem.
> Could somebody with a deeper understanding of Gorm please look into this 
> issue?
> 
> Fred
> 
> Fred Kiefer wrote:
>> Last week I tried to resolve a circular refernce problem between 
>> NSWindow and NSGraphicsContext.
>>
>> The source of the problem is that when an NSWindow gets displayed it 
>> generates an NSGraphicsContext (or rather a subclass) which will then 
>> manage all the actual drawing. The window retain the context and the 
>> context has an info dictionary which includes the window. That way we 
>> already start off with a circular reference. To break this I released 
>> the window once, to adjust the retain count. Now when the window gets 
>> deallocated I first do a retain on it and then release the graphics 
>> context which will in turn result in a release on the window. Or so I 
>> hoped. There were a few issues with my original code. The graphics 
>> context and the dictionary where autorelease objects, so I had to 
>> postpone the deallocation of the window by returning from dealloc and 
>> let it be called again. This also needed a bit of isa sizzling as 
>> subclasses will not be aware of that reference counting trick and wont 
>> be prepared to get dealloc called twice. (And the code in NSWindow 
>> dealloc needed to be reentrant as well)
>>
>> With that all resolved I expected my code now to work correctly, but 
>> this still isn't the case. As it turns out, calling retain on an object 
>> that already was about to get released wont have the expected result. 
>> When a release is send to an object with a retain count of 1, that count 
>> wont be changed! Now this means that I have to differentiate between 
>> calls to _termianteWindow that come from dealloc, where I don't call the 
>> retain and calls for oneShot windows, where I need to increase the 
>> retain count before freeing the context.
>>
>> All of this now looks like an even bigger mess then the one I started 
>> with and now any help on how to clearly solve this would be welcome.
>>
>> Cheers,
>> Fred
>>
>> PS: Some of the code I talk about above is still not committed.


      




reply via email to

[Prev in Thread] Current Thread [Next in Thread]