C# Garbage Collection of “Drawing” Objects inside a FrameworkElement within an ObservableCollection

Question

4.00/5 (1 vote)

See more:

Hi,

I have an ItemsPanel extended with my IscrollInfoLogic, ContainerGenerator etc.. (Virtualizing)

The ItemsPanel contains FrameworkElements which have a Property type of Drawing.

If the Item is visible i do:
On the Onrender if the DrawingProperty is not null i go with dc.DrawDrawing(*).
else
If it's not visible i just nullify the Drawing property to be eligible for GC.

The ammount of Ram being used just before the GC starts collecting are insane and even after the collection seems that something is being left.

For being more accurate:

C#

// This is Freezed() and is being set by an async service
            public Drawing PageDraw
        {
            get
            {
                return m_PageDraw;
            }
            set
            {
                if (m_PageDraw != value)
                {
                    m_PageDraw = value;
                    InvalidateVisual();
                }
            }
        }

        private Drawing m_PageDraw;

        protected override void OnRender(DrawingContext dc)
        {
            base.OnRender(dc);

            dc.DrawRectangle(Brushes.LightGray, new Pen(Brushes.Black, 1), new Rect(0, 0, Width, Height));

            if (PageDraw != null )
            {
                dc.DrawDrawing(PageDraw); // If i do not do this the memory taken increasing and decreasing within reasonable limits and time
            }
        }

        void DummyEllement_Unloaded(object sender, RoutedEventArgs e)
        {
            PageDraw = null;  
        }

The Drawing consist of various Bitmaps sometimes small sometimes big.
The results are the same even if i use only small bitmaps.

To avoid long threads consider the following:
1. Wpf native BitmapCache is not being used since i create my BitmapImage with Stream // So no leak or huge number here.
2. The stream and the Bitmap itself are being disposed right after the Drawing is RenderClosed() // Also the stream is a stream inside a stream to avoid the wpf's annoying "ownage stream behavior"

Posted 23-Sep-12 1:36am

BeStelios

Updated 23-Sep-12 1:42am

v2

Add a Solution

Comments

Sergey Alexandrovich Kryukov 23-Sep-12 11:25am

Where is the definition of the type "Drawing"?
--SA

BeStelios 23-Sep-12 11:29am

Seriously...
http://msdn.microsoft.com/en-us/library/system.windows.media.drawing(v=vs.100).aspx

Sergey Alexandrovich Kryukov 23-Sep-12 12:11pm

Oops! My bad, I mechanically asked... Thank you for clarification, I'll look at your question again...

So, what makes you thinking that you have memory leak or something? When you talk about the RAM used, how do you know it. For example, if you simply looked at Task Manager, you would have very inaccurate results...
--SA

BeStelios 23-Sep-12 14:07pm

When i say there is a leak or that the Garbage Collector is simply leaving things behind because they are somehow referenced there is no possibility that my results are inaccurate.

Actually the fact that i created a question means that i have double,triple,x checked.

I know there is a leak because:
Program Starts at 70Mb.
After some scrolls up - down we go to 1.3 GB.
Then a collection is being executed and you can notice the memory Drops to 800-900 where it should be MAX 160-200.

Also keep in mind :
dc.DrawDrawing(PageDraw); // If i do not do this the memory taken increasing and decreasing within reasonable limits and time.
What are the reasonable limits ? -> Without the rendering the Memory with continuous scrolling reaches 400-450 and then drops to 120.

So somehow the drawing after used for render on the framework element is being referenced/weakreferenced EVEN when the element is no longer Visible and even when its property m_PageDraw is null.

*Edit: Also note that the GC might start when the limit is reached (x86 or x64) making the whole OS hang for 1-2 secs.
Rare cases have thrown "out of memory exception" too.

Sergey Alexandrovich Kryukov 23-Sep-12 14:49pm

That seems somewhat weird to me, but perhaps there is something to think about.

Anyway, I just can say for sure that, despite of one common naive misconception, the memory leaks in the managed systems is quite possible, but all such leaks could be called "by-design leaks". It's all boils down to understanding of a leak. It's easy to design a demonstration of such leak, harder to analyze some existing design...

--SA

Sergey Alexandrovich Kryukov 23-Sep-12 14:54pm

You can do some extra investigations by writing some destructors in order to log the destruction cases. But you should understand that GC is not "obliged" to reclaim object resources even for an unreachable object by the moment of time you consider as expected. If there is no a real leak, it could be possible that the lack of destruction you see right now will turn into sooner destruction if you create a situation of scarce memory, by artificially holding some memory by some other process (there are special tools for that purpose). I would try that...
--SA

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)