Re: Rework of NSView diesplay mechanism
Hi Greg, thank you for pointing out this problem. I think that in this specific case the error lies with Gorm. What happens is that the displayRectIgnoringOpacity: method in GormViewEditor calls the super implementation of displayIfNeededInRectIgnoringOpacity:. This method on NSView now calls displayRectIgnoringOpacity:, which isn't a too strange behaviour, but now Gorm ends up in an infinite loop. It is surprising that the code there has ever worked. This was due to a specific implementation in NSView; I wouldn't be to surprised to see that Gorm wont work on Cocoa. The solution is obvious. Replace the super call to displayIfNeededInRectIgnoringOpacity: with one to displayRectIgnoringOpacity:. With the new code in NSView in place you wont even need the displayIfNeededInRectIgnoringOpacity: method, as now all display operations go through displayRectIgnoringOpacity:. And I am even wondering if it isn't possible to move all this code into drawRect:, but I might have missed the point here. I also don't understand the idea behind the currently_displaying variable. Is this really needed? Are you going to change the Grom code, or should I do it? I would prefer that you look at the code, as I don't want to break Gorm. Cheers, Fred Gregory John Casamento wrote: Fred, Upon seeing your notification of these changes... I tested with Gorm. The changes appear to cause Gorm to go into an infinite recursion when trying to select a control (such as a button) in a window. I have entered a bug for this... https://savannah.gnu.org/bugs/?20274. I'm not certain if it's Gorm's problem or the new changes in NSView, but we should look into it. Thanks, GJC -- Gregory Casamento - Original Message From: Fred Kiefer [EMAIL PROTECTED] To: GNUstep Developer gnustep-dev@gnu.org Sent: Tuesday, June 26, 2007 1:03:30 PM Subject: Rework of NSView diesplay mechanism I just submitted a change that reworks the NSView display mechanism to us the new method displayRectIgnoringOpacity:inContext:. To me the new code looks a lot more logical and consistent than the old one, but as this may only be a private opinion I would like you all to review and test the new code. I tried to document the display mechanism a bit better. That way you should be able to tell, what I want to achieve with the new code and point out errors in it. What I also would like to know is if there is any perceivable difference in performance. I don't expect any, but you never know. Cheers, Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Rework of NSView diesplay mechanism
Fred, Thanks for looking into this. I will make some changes and do some tests later this afternoon to see if it corrects the issue. Later, GJC -- Gregory Casamento - Original Message From: Fred Kiefer [EMAIL PROTECTED] To: Gregory John Casamento [EMAIL PROTECTED] Cc: GNUstep Developer gnustep-dev@gnu.org Sent: Wednesday, June 27, 2007 4:30:25 AM Subject: Re: Rework of NSView diesplay mechanism Hi Greg, thank you for pointing out this problem. I think that in this specific case the error lies with Gorm. What happens is that the displayRectIgnoringOpacity: method in GormViewEditor calls the super implementation of displayIfNeededInRectIgnoringOpacity:. This method on NSView now calls displayRectIgnoringOpacity:, which isn't a too strange behaviour, but now Gorm ends up in an infinite loop. It is surprising that the code there has ever worked. This was due to a specific implementation in NSView; I wouldn't be to surprised to see that Gorm wont work on Cocoa. The solution is obvious. Replace the super call to displayIfNeededInRectIgnoringOpacity: with one to displayRectIgnoringOpacity:. With the new code in NSView in place you wont even need the displayIfNeededInRectIgnoringOpacity: method, as now all display operations go through displayRectIgnoringOpacity:. And I am even wondering if it isn't possible to move all this code into drawRect:, but I might have missed the point here. I also don't understand the idea behind the currently_displaying variable. Is this really needed? Are you going to change the Grom code, or should I do it? I would prefer that you look at the code, as I don't want to break Gorm. Cheers, Fred Gregory John Casamento wrote: Fred, Upon seeing your notification of these changes... I tested with Gorm. The changes appear to cause Gorm to go into an infinite recursion when trying to select a control (such as a button) in a window. I have entered a bug for this... https://savannah.gnu.org/bugs/?20274. I'm not certain if it's Gorm's problem or the new changes in NSView, but we should look into it. Thanks, GJC -- Gregory Casamento - Original Message From: Fred Kiefer [EMAIL PROTECTED] To: GNUstep Developer gnustep-dev@gnu.org Sent: Tuesday, June 26, 2007 1:03:30 PM Subject: Rework of NSView diesplay mechanism I just submitted a change that reworks the NSView display mechanism to us the new method displayRectIgnoringOpacity:inContext:. To me the new code looks a lot more logical and consistent than the old one, but as this may only be a private opinion I would like you all to review and test the new code. I tried to document the display mechanism a bit better. That way you should be able to tell, what I want to achieve with the new code and point out errors in it. What I also would like to know is if there is any perceivable difference in performance. I don't expect any, but you never know. Cheers, Fred ___ 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: Rework of NSView diesplay mechanism
Fred, You were correct. I replaced the call with the one you suggested and it now works properly. I'm going to test it a bit more to see if there are any other issues. Thanks, GJC -- Gregory Casamento - Original Message From: Fred Kiefer [EMAIL PROTECTED] To: Gregory John Casamento [EMAIL PROTECTED] Cc: GNUstep Developer gnustep-dev@gnu.org Sent: Wednesday, June 27, 2007 4:30:25 AM Subject: Re: Rework of NSView diesplay mechanism Hi Greg, thank you for pointing out this problem. I think that in this specific case the error lies with Gorm. What happens is that the displayRectIgnoringOpacity: method in GormViewEditor calls the super implementation of displayIfNeededInRectIgnoringOpacity:. This method on NSView now calls displayRectIgnoringOpacity:, which isn't a too strange behaviour, but now Gorm ends up in an infinite loop. It is surprising that the code there has ever worked. This was due to a specific implementation in NSView; I wouldn't be to surprised to see that Gorm wont work on Cocoa. The solution is obvious. Replace the super call to displayIfNeededInRectIgnoringOpacity: with one to displayRectIgnoringOpacity:. With the new code in NSView in place you wont even need the displayIfNeededInRectIgnoringOpacity: method, as now all display operations go through displayRectIgnoringOpacity:. And I am even wondering if it isn't possible to move all this code into drawRect:, but I might have missed the point here. I also don't understand the idea behind the currently_displaying variable. Is this really needed? Are you going to change the Grom code, or should I do it? I would prefer that you look at the code, as I don't want to break Gorm. Cheers, Fred Gregory John Casamento wrote: Fred, Upon seeing your notification of these changes... I tested with Gorm. The changes appear to cause Gorm to go into an infinite recursion when trying to select a control (such as a button) in a window. I have entered a bug for this... https://savannah.gnu.org/bugs/?20274. I'm not certain if it's Gorm's problem or the new changes in NSView, but we should look into it. Thanks, GJC -- Gregory Casamento - Original Message From: Fred Kiefer [EMAIL PROTECTED] To: GNUstep Developer gnustep-dev@gnu.org Sent: Tuesday, June 26, 2007 1:03:30 PM Subject: Rework of NSView diesplay mechanism I just submitted a change that reworks the NSView display mechanism to us the new method displayRectIgnoringOpacity:inContext:. To me the new code looks a lot more logical and consistent than the old one, but as this may only be a private opinion I would like you all to review and test the new code. I tried to document the display mechanism a bit better. That way you should be able to tell, what I want to achieve with the new code and point out errors in it. What I also would like to know is if there is any perceivable difference in performance. I don't expect any, but you never know. Cheers, Fred ___ 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