> > performing a fl_read_image *after* fl_end_offscreen() simply=20 > > causes an ugly segmentation fault. > > This is awkward, the offscreen buffer still should exist, I'd=20 > > expect fl_delete_offscreen( offscreen ) to completely remove=20 > > the offscreen (so obviously any interaction after the delete=20 > > is doomed to fail). > > why should I be forced to copy the offscreen while it still=20 > > is the active context? I'd rather be free to copy it whenever=20 > > I want, as long as the offscreen doesn't get deallocated. > > fl_read_image only handles the current context, so if you want to read > from the offscreen, it has to be current. > That's just the way it is, I'm sorry. A lot of what you are doing is > really non-standard, so to some extent you are stretching the > implementation beyond its intended purpose.
Is it? I felt I just needed some more flexibility/usability from the offscreen. But I confess, I'm struggling with fltk while understanding how far it's (intended and real) functionality stretches ... Besides this, making such a functionality easier to use can make more users interested in it. More users can promote the functionality to be "standard", and so on ... but in truth I can't tell if a more flexible and complete offscreen is potentially interesting. > > Another small details: I deallocate the pixmap by delete[],=20 > > but is it allocated by new[]? otherwise this could be another=20 > > source of instability. > > I hope you all work with the new/delete operator guys ... > > The pixmap used by fl_read_image? If you read the docs, you will find > the answer to that question. you are right: uchar *fl_read_image(uchar *p, int X, int Y, int W, int H, int alpha = 0); Read a RGB(A) image from the current window or off-screen buffer. The p argument points to a buffer that can hold the image and must be at least W*H*3 bytes when reading RGB images and W*H*4 bytes when reading RGBA images. If NULL, fl_read_image() will create an array of the proper size which can be freed using delete[]. _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
