FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Cairo Context memory management.

 
Post new topic   Reply to topic     Forum Index -> gtkD
View previous topic :: View next topic  
Author Message
teales



Joined: 21 May 2007
Posts: 24
Location: Bangalore

PostPosted: Thu Sep 01, 2011 6:16 am    Post subject: Cairo Context memory management. Reply with quote

There seems to be conflict or mismatch in some areas of the library between the garbage collection in D, and the reference counting system used by GTK objects.

In the application I'm working on, I can drag objects about on a DrawingArea with the mouse. Not surprisingly this results in numerous re-renderings to some cairo context. I noticed that this was eating up the memory of my machine, particularly in cases where the DrawingArea was large. Surprisingly the accumulation of memory did not go away when the repeated activity ceased.

The context was created from the DrawingArea window at each go, and attempts to cache it did not get me anywhere. It would fine work the first time, and then silently fail.

I could fix the memory eating by putting in an explicit context.destroy() at the end of my render function. But the destructor for Context calls the same function, and this resulted in a fatal error from GTK when the garbage collector gets round to cleaning the D object up.

To get the stuff to work I removed my call to destroy(), wrapped the code that did the rendering in a scope, counted how many times it was called, then after every 10 renderings explicitly called GC.collect().

This does the trick - you can see the sawtooth effect in the memory usage display of the system monitor.

It seems to me that operations at such low level should be hidden somehow in the gtkD library. It occurs to me though that there there could be a catch 22 mismatch between the two memory management paradigms.
Back to top
View user's profile Send private message Send e-mail
Mike Wey



Joined: 07 May 2007
Posts: 428

PostPosted: Fri Sep 02, 2011 10:47 am    Post subject: Reply with quote

So the GC doesn't run often enough to keep the memory usage low when drawing.
We should at least allow calling destroy manually without crashing.
Back to top
View user's profile Send private message
teales



Joined: 21 May 2007
Posts: 24
Location: Bangalore

PostPosted: Fri Sep 02, 2011 12:43 pm    Post subject: Reply with quote

Mike,

Yes, that sounds sensible. How is not that clear to me. Could the destructor and the gtkD destroy() function test for the remaining reference count and behave accordingly. Also is the GTK+ memory management synchronous or asynchronous. If D is one, and GTK+ is the other, then it could be difficult.

And, to be fair, prodding the GC is not that bad a solution - maybe the change could be along that line.

However, this must have been handled by Python, and PHP, and so on, so there should be precedents.

When I've finished what I'm doing I shall be rather familiar with gtkD, so if you need a helper, let me know.

Steve
Back to top
View user's profile Send private message Send e-mail
Mike Wey



Joined: 07 May 2007
Posts: 428

PostPosted: Sat Sep 03, 2011 9:12 am    Post subject: Reply with quote

teales wrote:
Mike,

Yes, that sounds sensible. How is not that clear to me. Could the destructor and the gtkD destroy() function test for the remaining reference count and behave accordingly. Also is the GTK+ memory management synchronous or asynchronous. If D is one, and GTK+ is the other, then it could be difficult.


svn r894 adds the reference count check. As far as i know the GTK+ memory management is synchronous.

Quote:
And, to be fair, prodding the GC is not that bad a solution - maybe the change could be along that line.

However, this must have been handled by Python, and PHP, and so on, so there should be precedents.


The memory management in PHP usually relies in the process exiting at the end of the request, and doesn;t do a lot of freeing when running.
It might be a good idea to look at how Python does things.

Quote:
When I've finished what I'm doing I shall be rather familiar with gtkD, so if you need a helper, let me know.

Steve


Just don't run away screaming when reading some parts of the source for gtkwrap Wink
Back to top
View user's profile Send private message
Mike Wey



Joined: 07 May 2007
Posts: 428

PostPosted: Sun Sep 04, 2011 12:58 pm    Post subject: Reply with quote

Mike Wey wrote:
teales wrote:
However, this must have been handled by Python, and PHP, and so on, so there should be precedents.


The memory management in PHP usually relies in the process exiting at the end of the request, and doesn;t do a lot of freeing when running.
It might be a good idea to look at how Python does things.


It looks like pyCairo relies on the Python garbage collector.
Back to top
View user's profile Send private message
teales



Joined: 21 May 2007
Posts: 24
Location: Bangalore

PostPosted: Sun Sep 04, 2011 10:30 pm    Post subject: Reply with quote

Run away screaming! You should see mine - not a private or protected member variable in sight.

The proof of the pudding is the eating, and I've got a long way into what I'm working on without hitting any real problem with gtkD.
Back to top
View user's profile Send private message Send e-mail
Display posts from previous:   
Post new topic   Reply to topic     Forum Index -> gtkD All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group