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 !
on 2013-10-18 18:44
on 2013-10-23 17:32
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.
on 2013-10-23 18:34
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 <firstname.lastname@example.org> "Re: [ruby-gnome2-devel-en] Memory allocation problem with my Gtk program (using Cairo)" on Wed, 23 Oct 2013 15:32:54 +0200,
on 2013-10-23 22:40
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 !
on 2013-10-24 11:34
Hello, 2013/10/24 67Daidalos .. <email@example.com>: > 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
on 2013-10-24 23:06
A thousand times thank you Yokoyama-san ! I tried both and they work well ! You rocks !
on 2013-10-25 09:08
2013/10/25 67Daidalos .. <firstname.lastname@example.org>: > A thousand times thank you Yokoyama-san ! > > I tried both and they work well ! You rocks ! We did it! ;-) -- Masafumi Y. GitHub: myokoym