Okay: I’m on a linux system, so if you are windows I’m sure you can
figure out how to do the equivalent of some of the actions I describe
below
Create ‘test.svg’ as such:
<svg>
<circle cx="100" cy="100" r="100"/>
</svg>
Now create this little ruby script:
#!/usr/bin/env ruby
require 'gtk2'
Gtk::init
pixbuf = Gdk::Pixbuf.new "test.svg"
window = Gtk::Window.new.add(image =
Gtk::Image.new(pixbuf)).show_all
window.signal_connect(“destroy”) do Gtk.main_quit end
Gtk::timeout_add(1000) do
pixbuf = Gdk::Pixbuf.new “test.svg”
image.pixbuf = pixbuf
true
end
Gtk::main
All this script does is reload and display the svg file. Go ahead and
run the script and in a separate terminal run:
watch -n 1 ps -o rss -p <pid>
You’ll notice a fairly significant memory leak here. Also, if you change
the svg circle definition to:
<circle cx="400" cy="400" r="400"/>
You’ll notice the memory leak is significantly worse.
It appears the image is not releasing its old pixbufs for some reason
… is there a workaround for this? Is this expected behavior? Is there
a way to manually release the buffer? Thanks for any help!
Cheers
Crap …
So found my problem moments after posting … after having already
discovered this resolution before, I tossed it aside because I didn’t
have a latest set of gtk libraries. Looks like I need v0.19.3 and then
add the GC.start to avoid the memory leak issue. (as show below)
Thanks and Cheers --Reed
Reed Debaets wrote:
Okay: I’m on a linux system, so if you are windows I’m sure you can
figure out how to do the equivalent of some of the actions I describe
below
Create ‘test.svg’ as such:
<svg>
<circle cx="100" cy="100" r="100"/>
</svg>
Now create this little ruby script:
#!/usr/bin/env ruby
require 'gtk2'
Gtk::init
pixbuf = Gdk::Pixbuf.new "test.svg"
window = Gtk::Window.new.add(image =
Gtk::Image.new(pixbuf)).show_all
window.signal_connect(“destroy”) do Gtk.main_quit end
Gtk::timeout_add(1000) do
pixbuf = Gdk::Pixbuf.new “test.svg”
image.pixbuf = pixbuf
true
end
Gtk::main
All this script does is reload and display the svg file. Go ahead and
run the script and in a separate terminal run:
watch -n 1 ps -o rss -p <pid>
You’ll notice a fairly significant memory leak here. Also, if you change
the svg circle definition to:
<circle cx="400" cy="400" r="400"/>
You’ll notice the memory leak is significantly worse.
It appears the image is not releasing its old pixbufs for some reason
… is there a workaround for this? Is this expected behavior? Is there
a way to manually release the buffer? Thanks for any help!
Cheers
As I’m running on RHE5, what was the earliest version that Gnome 2 was
correctly releasing memory to a GC.start? (I’m in dependency hell on
configuration controlled machines that no-one wants to compile libraries
on sad face so I need rpms and of course … the redhat/centos/fedora
mess has some stupid dependency issues when you upgrade too far.
Thanks! --Reed
Reed Debaets wrote:
Crap …
So found my problem moments after posting … after having already
discovered this resolution before, I tossed it aside because I didn’t
have a latest set of gtk libraries. Looks like I need v0.19.3 and then
add the GC.start to avoid the memory leak issue. (as show below)
Thanks and Cheers --Reed
Reed Debaets wrote:
I was able to upgrade to ruby-gtk2-0.19.3-3 on my RHE5 system
It appears the memory leak is still there. Strangely, it is not there
under my Ubuntu system running libgtk2-ruby v0.19.3-1ubuntu3 (deb)
any ideas?
Reed Debaets wrote:
As I’m running on RHE5, what was the earliest version that Gnome 2 was
correctly releasing memory to a GC.start? (I’m in dependency hell on
configuration controlled machines that no-one wants to compile libraries
on sad face so I need rpms and of course … the redhat/centos/fedora
mess has some stupid dependency issues when you upgrade too far.
Thanks! --Reed
Reed Debaets wrote:
Crap …
So found my problem moments after posting … after having already
discovered this resolution before, I tossed it aside because I didn’t
have a latest set of gtk libraries. Looks like I need v0.19.3 and then
add the GC.start to avoid the memory leak issue. (as show below)
Thanks and Cheers --Reed
Reed Debaets wrote: