On Fri, 13 Mar 2009 11:34:05 +0100, Emmanuele Bassi
<[email protected]> wrote:
On Fri, 2009-03-13 at 09:45 +0100, Lukas Ruetz wrote:
On Mon, 09 Mar 2009 12:36:40 +0100, Lukas Ruetz <[email protected]>
wrote:
>>> My application is a simple version of an image-slideshow. When the
next
>>> image is shown I call clutter_actor_destroy(previousActor) on the
old
>>> actor.
>>> Is that enough to free the memory used by the texture?
>>
>> yes.
Hi,
please let me ask once again. Also this simple test-app I've attached
does
not free the image-memory during runtime. If calling
clutter_actor_destroy()
is enough as you say, then why is the memory not freed?
let me tell you once again: Clutter uses the slice allocator from GLib,
which pre-allocates memory regions (called "magazines") and manages the
reclamation of the released memory and hand-out of new allocations. the
memory usage is stable.
please, read:
http://library.gnome.org/devel/glib/stable/glib-Memory-Slices.html
and:
http://library.gnome.org/devel/gtk-faq/stable/x702.html
if you use valgrind following the instructions of the wiki page I linked
in my first reply you'll see that the memory usage is correct.
ciao,
Emmanuele.
Hi Emmanuele,
today I compiled clutter-0.9.2 and the memory usage is stable as it should
be.
I downloaded 0.9.0 again and compiled the test-app - then again no memory
was freed.
I think we've talked about two different things because you propably didn't
experience the problem as I did on my system. With "does not free memory"
I meant:
- the memory usage increases till the RAM is full
- after the RAM is full, the system starts to cache to use swap-space
- the system gets slower because of disk-IO and finally freezes
From the pages that you've pointed me to I now understand that glib caches
already "freed" memeory for later reuse. But the symtoms described above
have
been the reason why I kept complaining that this could not be the intended
behaviour.
I've tested 0.9.2 on another PC too and everything is ok now. (Both
systems are
ubuntu 8.10 systems)
thanks for your time,
Lukas
--
To unsubscribe send a mail to [email protected]
