[wxPython-users] wx on MSW: leaked GDI region objects

[Doug Anderson]

Robin,

Thanks for the followup.  I've filed the sourceforge bug.  If anyone  
else is interested in following this, I believe that this URL will  
get you there:
	http://sourceforge.net/tracker/index.php? 
func=detail&aid=1819635&group_id=9863&atid=109863

To answer your questions:

1. We have thousands of objects.  We considered redesigning, but the  
problem is that everything works pretty well as it is (aside from the  
GDI issue), so changing the design doesn't seem to make sense in our  
case.  I would imagine that getting a system of sizers/coordinate  
translators/painters written in python that worked as quickly as the  
native one in wxWidgets might take some time.  Reducing the number of  
objects on the screen is also possible, but non-ideal in our case.   
Obviously, if we can't get things resolved then redesign is our only  
option.

2. Doing the "Destroy" does seem to work without any crashes.  I've  
incorporated it into our code (where possible--we can only use this  
when we do a custom paint) and my GDI objects has gone dramatically  
down.  I will continue to do further testing.


-Doug

---

On Oct 24, 2007, at 3:23 PM, Robin Dunn wrote:

> Doug Anderson wrote:
>> Hello,
>> I'm working on a wxPython application that can potentially have  
>> _lots_ of objects on the screen.
>
> How many is lots?  Dozens or small hundreds I wouldn't worry about.  
> Large hundreds or thousands then I would say that you should  
> seriously rethink the design of your application, even if this bug  
> gets fixed...
>
>
>
>
>> I believe that the problem is in: "bool wxWindowMSW::HandlePaint 
>> ()".  Specifically, it creates a wxRegion and then stores it in a  
>> member variable on this line: "m_updateRegion = wxRegion((WXHRGN)  
>> hRegion);".  As far as I can tell (I'm not an expert at all in the  
>> wxWidgets source base), this member variable is never cleared (so  
>> the region refcount is never decremented) until the next time the  
>> paint comes around.  When the next paint comes around, the old  
>> variable no longer has a reference, but we've created a new one to  
>> take its place.
>
> C++ will automatically destroy the old object at this point.
>
>> Possible hacky workaround:
>> Putting this in my paint event seems to fix the problem.  I'm not  
>> suggesting it's a good idea since I don't know all of the  
>> consequences, but it does plug up the leak:
>>         updateRegion = self.GetUpdateRegion()
>>         updateRegion.Destroy()
>> --
>
>
>> My requests:
>> 1. I'd love it if someone could fix the wxWigets source base.   
>> That would probably be the most ideal for us.
>
> Please make a bug report for this at wxWidgets's SourceForge page.  
> http://sourceforge.net/tracker/?group_id=9863&atid=109863&func=add
>
> BTW, since the count remains stable instead of constantly  
> increasing forever then this really isn't a leak.  However the fact  
> that the the widgets are holding on to that region handle may still  
> be questionable behavior, but one of our MSW experts is going to  
> have to be the one to look into it and decide.  They will see the  
> bug report.
>
>
>> 2. If someone can validate that my hacky workaround (above) is not  
>> _too_ bad (or what the side effects are), it gives us an option to  
>> use it until a fix is in wxWidgets.
>
> I would expect there to be some double deletions happening, but if  
> it's not crashing when you do this then I'm probably missing  
> something.
>
> -- 
> Robin Dunn
> Software Craftsman
> http://wxPython.org  Java give you jitters?  Relax with wxPython!
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wxPython-users-unsubscribe at lists.wxwidgets.org
> For additional commands, e-mail: wxPython-users- 
> help at lists.wxwidgets.org
>