Hi, I’m trying to write a program that uses a picture from the user’s
files to generate a random jigsaw puzzle. For that I’m using Gtk+ for
the UI, and Cairo to uses png images as mask for creating the pieces. It
works well as long as the base picture is not too large. For what I
tested so far, it works for 750x600 pictures (that generate a 25x20 ->
500 pieces puzzle) or lower, but not for 1020x660 (748 pieces) or higher
poping up an alert message saying :
“GLib-ERROR gmem.c:165 failed to allocate xxx bytes”
with the xxx growing up when the base picture is larger.
I join my code, even if you couldn’t run it (because you don’t have the
png files for the pieces) if someone has some ideas to make it consume
less memory when generating the pieces, it will be great.
I also mentioned in it another problem I have when trying to make a
user-parametrable application (here is a lighten version, I have another
code on different files for the final application). I add to it a menu
bar where the user can choose “New Puzzle”, it opens a Dialog where he
can set the source picture, the framing for it, and other stuff not yet
implemented. But when I get the infos the user entered, the pieces are
created (i used a debug line to be sure of it) but I can’t set them
visible, I tried a show() in th constructor of the Piece class, I tried
to yield layout.show-all, window.show-all, nothing worked. I guess it’s
because the image widgets are created after the Gtk.main command, but
even if I yield it again, it doesn’t work, and it set another bug with
the interpreter not closing after destroying the window. Once again, if
anyone has an hint to solve this, it will be welcome.
Sorry for my pitiful english !
Hi ! Just to advert peolpe who might try to help me that I solved the
second problem (i.e. the visibility of the pieces) by creating the
Gtk::Layout just before the pieces and realizing it only after all the
pieces were created.
But I still need some help with the memory problem. I have search the
net and found many other similar problems in other forums, but never can
find a way to get round it. It’s clearly a malloc limitation in the C
source code of Gtk, but I’m not really at ease with C language and
prefer not to interfere with it.
I thought that maybe threads can be an help, creating not parralel
threads, but successives ones, each taking care of a part of the pieces
creation process and terminating before the next thread take the relay,
do you think it could be a solution ?
Or is it a limitation in the number of widget a Gtk::Layout can hold ?
(I thought it doesn’t make sense to create a widget that is virtually
illimited in space if it must be limited in number of widget but
nevertheless)
In that case, did someone has an idea to get round that limitation ?
It might also be something else I can’t think of, so any help will be
appreciated.
Hi,
Could you also attach image files? We can’t run your script
without them. If you attach them, someone help you. 
Thanks,
kou
In [email protected]
“Re: [ruby-gnome2-devel-en] Memory allocation problem with my Gtk
program (using Cairo)” on Wed, 23 Oct 2013 15:32:54 +0200,
Here are the pieces png files. For the model image of the puzzle, just
choose any one on your computer.
Hope you’ll find smth !
A thousand times thank you Yokoyama-san !
I tried both and they work well ! You rocks !
Hello,
2013/10/24 67Daidalos … [email protected]:
Hope you’ll find smth !
How about this?:
# class Piece < Image ... def create_pixbuf ...
cai_con = Cairo::Context.new(surf1)
cai_con.set_source_pixbuf(@source, x_shift, y_shift)
surf2 = Cairo::ImageSurface.from_png(piece_path)
cai_con.mask(surf2, 0, 0)
cai_con.fill
cai_con.destroy # ********** added !!! **********
stride = surf1.stride
I think that the following is better way:
Cairo::Context.new(surf1) do |cai_con|
cai_con.set_source_pixbuf(@source, x_shift, y_shift)
surf2 = Cairo::ImageSurface.from_png(piece_path)
cai_con.mask(surf2, 0, 0)
cai_con.fill
end
stride = surf1.stride
–
Masafumi Y.
GitHut: myokoym
2013/10/25 67Daidalos … [email protected]:
A thousand times thank you Yokoyama-san !
I tried both and they work well ! You rocks !
We did it! 
–
Masafumi Y.
GitHub: myokoym