DIVA report #9

[MDK]

Done:
* Ported my whole drawing to Cairo. Some screenshot on the blog:

http://diva.mdk.org.pl/2005/08/26/cairo-cairo-cairo

* Got some patches against Mono.Cairo ready to send to Hisham.
It seems we need to upgrade the bidings to the newer version of Cairo.

* Moved my framecache to the unmanaged & implemented a nice,
threaded, balanced binary tree based lookup system.

* Implemented a basic plugin system with backend plugins working.

* More work on the internals. Contrary to my first
assumptions, Gdv is now a full G-Object based library that's (will be)
bound 1:1 to the managed.

Upcoming:

* Well, I just want to put together & tweak all the stuff I've
got to produce a nice demo.

Problems:

* I need to investigate into Mono.Cairo. It seems there are
some huge memory leaks. After a few dozen of GUI redrawing iterations
the memory usage goes to 500MB... sigh. This is even though I call all
the IDisposable methods manually, so I suppose it has something to do
with resources being lost in Graphics.Save / Restore.

--
Michał Dominik K.
michal...@gmail.com
www.mdk.org.pl

[miguel de icaza]

        * I need to investigate into Mono.Cairo. It seems there are
some huge memory leaks. After a few dozen of GUI redrawing iterations
the memory usage goes to 500MB... sigh. This is even though I call all
the IDisposable methods manually, so I suppose it has something to do
with resources being lost in Graphics.Save / Restore.

It is possible that Mono.Cairo is not correctly releasing its resources, I would not be surprised.

[MDK]

Well, it's calling the unmanaged *_destroy functions, so It should work. Also, if I disable all the drawing code (and leave only the Create/Dispose functions) it behaves as expected -- memory goes up and at some point GC kicks in and it gets freed.

Judging by the size of the leak, it seems that the whole areas of pixel memory are leaking.

[miguel de icaza]

Hello,

Hisham, can you weight in?

Well, it's calling the unmanaged *_destroy functions, so It should work. Also, if I disable all the drawing code (and leave only the Create/Dispose functions) it behaves as expected -- memory goes up and at some point GC kicks in and it gets freed.

I think we need to audit Mono.Cairo, if memory gets released during a GC it means that the release is happening not by calling IDisposable's method but its being called by the finalizers (which will run on a separate thread). 

So am not getting a very warm feeling about this.

[MDK]

On 8/27/05, miguel de icaza <miguel....@gmail.com> wrote:

I think we need to audit Mono.Cairo, if memory gets released during a GC it means that the release is happening not by calling IDisposable's method but its being called by the finalizers (which will run on a separate thread). 

Well, I investigated a bit more into that. The results are very confusing. It seems that the memory leaks ONLY if I use the Graphics.Stroke method. If I draw using Graphics.Fill everything is ok (I'm talking here about very simple drawing -- basic shapes and lines)

Since the Graphics.Stroke() only calls the unmanaged cairo_stroke I'm really out of ideas here. Save/Restore have nothing to do with this.

I can't believe it's a bug in Cairo. I'll try to reproduce this in the native code, and let you know about the results.

[MDK]

[MDK]

On 8/28/05, MDK <michal...@gmail.com> wrote:

On 8/27/05, miguel de icaza <miguel....@gmail.com > wrote:

I think we need to audit Mono.Cairo, if memory gets released during a GC it means that the release is happening not by calling IDisposable's method but its being called by the finalizers (which will run on a separate thread). 

I can't believe it's a bug in Cairo. I'll try to reproduce this in the native code, and let you know about the results.

I did the test cases. The attached file contains a simple C program that draws (repeatedly) a rectangle and a C# version of it. The latter will eat all your memory in a metter of seconds. The sysdraw.cs comes from the svn (Mono.Cairo examples).

And now the part I don't understand -- In sysdraw.cs we've got a bunch of nasty X functions to create the target cairo surface and a small piece of an out-commented code:

// this can be safely removed now, just keep it for a bit more
//Cairo.Graphics g = new Cairo.Graphics (
//                    gdk_cairo_create (x_drawable ));

Why is this commented out? Once you remove the whole X code and leave just:

public static Cairo.Graphics CreateDrawable (Gdk.Drawable drawable)
{
        Cairo.Graphics g = new Cairo.Graphics
                               (gdk_cairo_create (drawable.Handle));
        return g;
}

It all works like expected, no leaks.

[MDK]

---------- Forwarded message ----------
From: Hisham Mardam Bey <hisham.m...@gmail.com>
To: michal...@gmail.com, Miguel de Icaza <mig...@novell.com>
Date: Fri, 2 Sep 2005 20:46:41 +0000
Subject: Re: Cairo leaks

> // this can be safely removed now, just keep it for a bit more
> //Cairo.Graphics g = new Cairo.Graphics (
> // gdk_cairo_create (x_drawable ));
>
> Why is this commented out? Once you remove the whole X code and leave just:
>

Miguel and I decided to comment this out because its based on the new
versions of gtk that have this function. Since we are not sure that
this function is available to all users, we do not want to use it. As
a matter of fact, the GTK and X11 samples are just a proof of concept
thing altogether. The PNG surface tests are really what is most
important.

When versions of GTK that support cairo and have this function are
more widespread and this becomes the de-facto GTK we can switch back
to using it.


--
Hisham Mardam Bey
MSc (Computer Science)
http://hisham.cc/
+9613609386
Codito Ergo Sum (I Code Therefore I Am)