> > On 4 Feb 2009, at 18:04, Jose Marcelo Auler wrote: > > > > The only disadvantage of this method(in comparison with direct > > draw) is only memory consumption, but I don't think > > In what way? I think this approach is fairly light on memory - where > do you think it is not? > > > You have to keep a redundant screen image on your memory most of the time(depending on your implementation), considering a 1024x768 window and 4 bytes per pixel(w/transparency) we would have 3145728 bytes(3MiB), and with a direct draw,in linux at least, X Server/tinyX would just forward to the framebuffer(no extra memory spent). But It's really not a big issue 3MiB of RAM to show a screen in most of the machines, so I don't think my comment was useful :) But another comment I have, maybe it's not so useful also :) , is that I implemented I really complex window with a lot of drawings with degrade(non-bitmap), animations, and I figured out that with Fl_Double_Window, resize operation became slower, a little weird. I know that this way best to not flick the window, and actually how It is so complex, it delays to show everything in the resize animation rate instead of showing the live drawing, but this behavior wasn't so good. I probably will work out resize operations to fix that, but It's something to consider, if you do not need to use double buffer, keep it simple with Fl_Window or just double buffer some elements.
Best Regards, J.Marcelo Auler _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
