Re: NSWindow & NSGraphicsContext issue

[Gregory John Casamento]

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.



_______________________________________________
Gnustep-dev mailing list
address@hidden
http://lists.gnu.org/mailman/listinfo/gnustep-dev



      


_______________________________________________
Gnustep-dev mailing list
address@hidden
http://lists.gnu.org/mailman/listinfo/gnustep-dev