View previous topic :: View next topic |
Author |
Message |
teales
Joined: 21 May 2007 Posts: 24 Location: Bangalore
|
Posted: Thu Sep 01, 2011 6:16 am Post subject: Cairo Context memory management. |
|
|
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 |
|
|
Mike Wey
Joined: 07 May 2007 Posts: 428
|
Posted: Fri Sep 02, 2011 10:47 am Post subject: |
|
|
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 |
|
|
teales
Joined: 21 May 2007 Posts: 24 Location: Bangalore
|
Posted: Fri Sep 02, 2011 12:43 pm Post subject: |
|
|
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 |
|
|
Mike Wey
Joined: 07 May 2007 Posts: 428
|
Posted: Sat Sep 03, 2011 9:12 am Post subject: |
|
|
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 |
|
Back to top |
|
|
Mike Wey
Joined: 07 May 2007 Posts: 428
|
Posted: Sun Sep 04, 2011 12:58 pm Post subject: |
|
|
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 |
|
|
teales
Joined: 21 May 2007 Posts: 24 Location: Bangalore
|
Posted: Sun Sep 04, 2011 10:30 pm Post subject: |
|
|
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 |
|
|
|
|
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
|