Hi,
thanx to everybody, I managed through the offscreen and the draw() troubles and
my application now works.
I have a last remark, concerning the "fragility" of the offscreen ... I did the
following:
void draw( ) {
if ( d_useOffscreen ) {
CoordPair const offscreenSize = GUImaxtreePanelWidgets::size_group( );
// init the offscreen in the right way:Fl::flush( );this->make_current(
); fl_delete_offscreen( d_offscreen );return Fl_create_offscreen( w, h );
Fl_Offscreen offscreen = initOffscreen( offscreenSize.getX( ),
offscreenSize.getY( ) );
fl_begin_offscreen( offscreen );
// draw the widget hierarchy of this group into the offscreen
GUImaxtreePanelWidgets::drawScrollPanel( );
uchar *treeScreenshot = fl_read_image( NULL, 0, 0, offscreenSize.getX( ),
offscreenSize.getY( ) );
fl_end_offscreen( );
writeScreenshot( treeScreenshot, offscreenSize.getX( ),
offscreenSize.getY( ) );
d_useOffscreen = false; // reset the flag, screenshot needs to be taken
only once
fl_delete_offscreen( offscreen );
delete[] treeScreenshot;
}
// standard drawing
GUImaxtreePanelWidgets::draw( );
}
The problem is that this is the only working sequence:
performing a fl_read_image *after* fl_end_offscreen() simply causes an ugly
segmentation fault.
This is awkward, the offscreen buffer still should exist, I'd expect
fl_delete_offscreen( offscreen ) to completely remove the offscreen (so
obviously any interaction after the delete is doomed to fail).
why should I be forced to copy the offscreen while it still is the active
context? I'd rather be free to copy it whenever I want, as long as the
offscreen doesn't get deallocated.
Another small details: I deallocate the pixmap by delete[], but is it allocated
by new[]? otherwise this could be another source of instability.
I hope you all work with the new/delete operator guys ...
Best,
Fabio
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
