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.

[miguel de icaza]

Post by MDK
* 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]

Post by MDK
* I need to investigate into Mono.Cairo. It seems there are

Post by MDK
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.

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.

Post by MDK
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.

Judging by the size of the leak, it seems that the whole areas of pixel

Post by MDK
memory are leaking.
--
Micha³ Dominik K.
www.mdk.org.pl <http://www.mdk.org.pl>

[MDK]

Post by miguel de icaza
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]

Post by MDK

Post by miguel de icaza
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 <***@gmail.com>
To: ***@gmail.com, Miguel de Icaza <***@novell.com>
Date: Fri, 2 Sep 2005 20:46:41 +0000
Subject: Re: Cairo leaks

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

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/
[phone]
Codito Ergo Sum (I Code Therefore I Am)

[Florian Gross]

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

Neat, looking very smooth. I guess it also allows for sexier animations
and so on? Eye candy is probably out of the scope of the SoC, but good
stuff. The alpha transparency on the line and marker is nice as well.

[miguel de icaza]

Hello,

Post by Florian Gross

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

Neat, looking very smooth. I guess it also allows for sexier animations
and so on? Eye candy is probably out of the scope of the SoC, but good
stuff. The alpha transparency on the line and marker is nice as well.

It is not out of scope.

A well done, polished application attracts users and developers. I think
that in DIVA's case it is a fundamental component of the project.