Hi guys, I got some problem in my project and I hope some one can help. The project is a control library. The user should be able to pass a drawing brush to the controls paint event, therefore I inherited the system PaintEventArgs class and added the Brush property to it.
Now, the problem is that when a PathGridinentBrush is assigned to the Brush property of the custom-PaintEventArgs the memory usage is growing but if a SolidBrush is used the memory usage stays normal. Also, I want to mention that the custom-PaintEventArgs object is disposed after the use. Here is the class:
vb Code:
Public Class PaintEventArgs
Inherits System.Windows.Forms.PaintEventArgs
Private _brush As Brush
Private _color As Color
Public Property Brush() As Brush
Get
'If brush is nothing then assign a solid brush
If Me._brush Is Nothing Then
Me._brush = New SolidBrush(Me._color)
End If
Return Me._brush
End Get
Set(ByVal value As Brush)
Me._brush = value
End Set
End Property
Sub New(ByVal brush_color As Color, ByVal graphics As System.Drawing.Graphics, ByVal clipRect As System.Drawing.Rectangle)
MyBase.New(graphics, clipRect)
Me._color = brush_color
End Sub
Protected Overrides Sub Dispose(ByVal disposing As Boolean)
Try
If disposing AndAlso Me._brush IsNot Nothing Then
Me._brush.Dispose()
End If
Finally
MyBase.Dispose(disposing)
End Try
End Sub
End Class
Thanks for any help.
VBDT
Last edited by VBDT; Apr 6th, 2008 at 08:43 PM.
Rating is a way of saying thank you. Don't forget to rate always!
The only thing I can think of at the moment, that really is an unlikely source of an object not being disposed, is to take a look at the code for the PathGradientBrush Class and see if there's an obvious problem with it's dispose method. That would assume the unlikely situation in which a base library class was written with a logic error.
The only thing I can think of at the moment, that really is an unlikely source of an object not being disposed, is to take a look at the code for the PathGradientBrush Class and see if there's an obvious problem with it's dispose method. That would assume the unlikely situation in which a base library class was written with a logic error.
Hi FourBlades, thanks for the response. As I can see with a reflector tool the "PathGradientBrush" class doesn’t override the "Dispose" method of the base class (Brush), that means it uses the base class method. But the "SolidBrush" class overrides the base "Dispose" method and sets a Boolean member value of its own and than calls the base method.
My tests show that there could be a possible bug in the "PathGradientBrush". Here is the test code I posted in MSDN forums if some one wants to test it himself.
It seems I stuck with this problem for now.
Last edited by VBDT; Apr 7th, 2008 at 06:48 PM.
Rating is a way of saying thank you. Don't forget to rate always!
Well then, assuming that it does not release some valuable resource, the next best thing would be to set each instance to Nothing and the GC do it's thing during the next couple of collections.
In fact if your program won't suffer for it, just call Collect after setting each instance to Nothing just to prevent the build-up.
Unfortunately, it will be very costly. At least, the app creates, uses and disposes five brushes every 100 millisecond. It will make the program very slow calling 50 times GC in a second, but thank you for the suggestion.
Rating is a way of saying thank you. Don't forget to rate always!
I did not scrutinize either class, but surely they did not forget to handle their resources. Maybe upon a close reading we'd see that it really wasn't needed in those classes?
Are you sure you did not miss anything in your own code?
It's just that I'd be very surprised if MS actually forgot to implement Dispose on these classes. If they did, it certainly needs to be fixed.
I did not scrutinize either class, but surely they did not forget to handle their resources. Maybe upon a close reading we'd see that it really wasn't needed in those classes?
Are you sure you did not miss anything in your own code?
It's just that I'd be very surprised if MS actually forgot to implement Dispose on these classes. If they did, it certainly needs to be fixed.
I created a test windows form project and posted the code in MSDN forums here. Check it out and try it, you will see that memory usage is constantly growing.
Here is the screen shot of a test that is running for two hours and it's memory usage is constantly growing.
Last edited by VBDT; Apr 7th, 2008 at 10:16 PM.
Rating is a way of saying thank you. Don't forget to rate always!
I think I found the source of the bug. It depends which constructor of the “PathGridientBrush” will be used. The buggy constructor is the constructor that takes points. I posted the constructor and pointed out what is the problem in MSDN forums here. Now when I use the constructor that takes GraphicsPath object the memory used is normal. I guess MS got to fix this problem in the near future.
Last edited by VBDT; Apr 8th, 2008 at 01:55 AM.
Rating is a way of saying thank you. Don't forget to rate always!
Oh, well if the memory is just growing by that much -- doesn't seem too extraordinary -- that's probably normal. I've seen and read where the runtime will consume more memory for an application at runtime by paging out some of the runtime overhead to make more room for the application. Maybe that's what's going on here.
[RESOLVED] Problem with brushs
Reply With Quote
Re: Problem with brushs
Originally Posted by FourBlades
