Re: NSWindow NSGraphicsContext issue
Original-Nachricht On Thu, 22 May 2008, Gregory John Casamento wrote: Given that Fabien said once he recreated the .gorm file it's not happening anymore and also that I can't make it happen in any other application, I believe we can consider this issue a non-issue. Is this true Fabien? I am currently away from my computer and cannot test this, but from looking at the code in NSWindow, GSClassSwaper and GSWindowTemplate I would still expect that initWithContentRect:... gets called twice on the same NSWindow object. (BTW, shouldn't GSClassSwapper release self in initWithCoder:, when returning the new object?) Greg, I understand it is hard to reproduce this without a proper example, but please try to look at the code and see what it does. One note for the future, however. I would really like everyone to start using the bug reporting system a little more. This helps us tackle bugs and enhancement requests to meet your desires for GNUstep faster since it is more easily tracked and is in one place as opposed to emails, IMs, private messages on IRC, etc. My fault. I will try to use it :) In this case it was also my fault. I should have put the remaining issue into our bug tracker, but it was so late at night, when I finally had your program more or less working. When I am back at my computer I will try to reproduce the problem with a tiny Gorm file and report it, if it still exists. Fred -- Super-Acktion nur in der GMX Spieleflat: 10 Tage für 1 Euro. Über 180 Spiele downloaden und spiele: http://flat.games.gmx.de ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: NSWindow NSGraphicsContext issue
Please, let's move this entire discussion to the bug tracker here: https://savannah.gnu.org/bugs/index.php?23336 Thanks, GJC Gregory Casamento -- Principal Consultant - OLC, Inc # GNUstep Chief Maintainer - Original Message From: Fred Kiefer [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: gnustep-dev@gnu.org Sent: Friday, May 23, 2008 6:45:58 AM Subject: Re: NSWindow NSGraphicsContext issue Original-Nachricht On Thu, 22 May 2008, Gregory John Casamento wrote: Given that Fabien said once he recreated the .gorm file it's not happening anymore and also that I can't make it happen in any other application, I believe we can consider this issue a non-issue. Is this true Fabien? I am currently away from my computer and cannot test this, but from looking at the code in NSWindow, GSClassSwaper and GSWindowTemplate I would still expect that initWithContentRect:... gets called twice on the same NSWindow object. (BTW, shouldn't GSClassSwapper release self in initWithCoder:, when returning the new object?) Greg, I understand it is hard to reproduce this without a proper example, but please try to look at the code and see what it does. One note for the future, however. I would really like everyone to start using the bug reporting system a little more. This helps us tackle bugs and enhancement requests to meet your desires for GNUstep faster since it is more easily tracked and is in one place as opposed to emails, IMs, private messages on IRC, etc. My fault. I will try to use it :) In this case it was also my fault. I should have put the remaining issue into our bug tracker, but it was so late at night, when I finally had your program more or less working. When I am back at my computer I will try to reproduce the problem with a tiny Gorm file and report it, if it still exists. Fred -- Super-Acktion nur in der GMX Spieleflat: 10 Tage für 1 Euro. Über 180 Spiele downloaden und spiele: http://flat.games.gmx.de ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: NSWindow NSGraphicsContext issue
On Thu, 22 May 2008, Gregory John Casamento wrote: Given that Fabien said once he recreated the .gorm file it's not happening anymore and also that I can't make it happen in any other application, I believe we can consider this issue a non-issue. One note for the future, however. I would really like everyone to start using the bug reporting system a little more. This helps us tackle bugs and enhancement requests to meet your desires for GNUstep faster since it is more easily tracked and is in one place as opposed to emails, IMs, private messages on IRC, etc. My fault. I will try to use it :) Fabien ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
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 [EMAIL PROTECTED] To: Fred Kiefer [EMAIL PROTECTED]; GNUstep Developer gnustep-dev@gnu.org 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 [EMAIL PROTECTED] To: GNUstep Developer gnustep-dev@gnu.org 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 Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: NSWindow NSGraphicsContext issue
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 [EMAIL PROTECTED] To: Gregory John Casamento [EMAIL PROTECTED] Cc: GNUstep Developer gnustep-dev@gnu.org 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 [EMAIL PROTECTED] To: Fred Kiefer [EMAIL PROTECTED]; GNUstep Developer gnustep-dev@gnu.org 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 [EMAIL PROTECTED] To: GNUstep Developer gnustep-dev@gnu.org 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 Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: NSWindow NSGraphicsContext issue
I'm apparently missing something,... I get an error trying to compile that. Gregory Casamento -- Principal Consultant - OLC, Inc # GNUstep Chief Maintainer - Original Message From: Fred Kiefer [EMAIL PROTECTED] To: Gregory John Casamento [EMAIL PROTECTED] Cc: GNUstep Developer gnustep-dev@gnu.org 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 [EMAIL PROTECTED] To: Fred Kiefer [EMAIL PROTECTED]; GNUstep Developer gnustep-dev@gnu.org 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 [EMAIL PROTECTED] To: GNUstep Developer gnustep-dev@gnu.org 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 Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: NSWindow NSGraphicsContext issue
On 18 May 2008, at 16:51, 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. Well ... my immediate thought is that the window should not be stored in the info dictionary. When a context is created, the contents of the attributes dictionary should be extracted and stored in ivars and either retained or not retained as appropriate for each attribute. When the -attributes method is called, a new dictionary should be generated from the attributes stored in ivars. Then the retain cycle goes away, and you can use a private method to allow a window to zero the ivar when it is deallocating itsself (if necessary: it isn't necessary unless the graphics context can somehow be used after the window is deallocated). ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: NSWindow NSGraphicsContext issue
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 [EMAIL PROTECTED] To: Fred Kiefer [EMAIL PROTECTED]; GNUstep Developer gnustep-dev@gnu.org 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 [EMAIL PROTECTED] To: GNUstep Developer gnustep-dev@gnu.org 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 Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
NSWindow NSGraphicsContext issue
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 Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: NSWindow NSGraphicsContext issue
Fred Kiefer fredkiefer at gmx.de writes: Last week I tried to resolve a circular refernce problem between NSWindow and NSGraphicsContext. The window in the dictionary is (should be) only used when creating the context : delete the dictionary after use or remove the window from the ddictionary. You might keep the window (if needed) in a non retained ivar : no cycle! Too simple...? Xavier ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
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 Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
