Hi,
> > Moreover, I also managed to create the offscreen outside the draw()
> > in the derived window, but then you need to precede the
> > fl_create_offscreen by Fl::flush( ); aWin->make_current( );
> > Alternatively you still can create it within the draw() function,
> > but I dislike that as it is an action to be taken once, so it's
> > ugly to have draw() check all the time for an initialized
> > pointer ... at least, in my opinion.
>
> This is always going to be a matter of opinion, of course.
> I much prefer to do it within the draw method, for a number of
> reasons, but mainly because that style is congruent with what you
> would do using many other graphical rendering contexts, e.g. that
> idiom is commonplace in OpenGL and Cairo code, and is widely understood.
>
> Ah! Perhaps you think that checking the rendering context is valid,
> whilst in the draw method, has a performance impact?
> Let me assure you that when it comes to rendering even a fairly
> simple view, the cost of one extra conditional test is undetectable.
> Even simple graphics operations chew cpu cycles up!
I'm not aware if this is such a widespread programming pattern. I did some
Computer Graphics as well and there the callback paradigm is used indeed all
the time, still it's a matter of common sense to prepare everything you need in
the init phase while in the callback only processing code is placed.
moreover, the very first thing they teach you at CS is to *avoid* to compute
all over the time anything you can compute just once and to think about
algorithms and scalability.
Not doing so can spare programming time, but in the long run it turns against
you ... or you follow the MS paradigm where any bad programming can be excused
by the expectation *coff* obligation of better hardware...
But more commonly it's claimed to be bad practice, isn't it?
> > I have two questions:
> >
> > a) including <FL/x.H> is ugly for cross-platform programming, can I
> > include an header automatically selecting x.h or win32.h or any
> > platform related header which is needed?
>
> That is exactly what x.H does - it is a wrapper for the appropriate
> platform-specific content. So you should include x.H on any platform,
> and the appropriate (X11, win32, OSX) stuff will then be included.
Ok, but this looks to me counter-intuitive ... I'd expect to include win32.h
when programming for windows, x.h for Linux and so on, including win32.h when
programming in Linux isn't straightforward to me, nor it is to include x.h when
programming in windows ... I'm doing cross-platform programming, so this
happens. Actually I'd like to include one single graphics-layer.h which
prepares everything for me.
> > b) so far the drawing is done through fl_rectf, would it work the
> > same way if full widgets are drawn?
>
> I assume by now you have seen my subclassed-Fl_Group example and know
> that the answer to this question is yes...
hi,
I see the example. I understand and agree it's also possible to feed a derived
class with the appropriate draw() method into fluid.
in the meanwhile I was trying to figure out a (hopefully) lesser invasive way
to just trigger the already present draw() method ... so I came up with the
following: this is code from the widget I'm using to render the window holding
my graph of (complex) widgets:
class GUImaxtreePanel : public GUImaxtreePanelWidgets {
..
/*
* the offscreen to draw
*/
Fl_Offscreen d_offscreen;
/*
* the offscreen control flag
*/
bool d_useOffscreen;
..
void initOffscreen( unsigned w, unsigned h ) {
Fl::flush( );
this->make_current( );
fl_delete_offscreen( d_offscreen );
d_offscreen = fl_create_offscreen( w, h );
std::cout << "Fl_Offscreen created" << std::endl;
}
void draw( ) {
if ( d_useOffscreen ) {
CoordPair offscreenSize = GUImaxtreePanelWidgets::size_group( );
initOffscreen( offscreenSize.getX( ), offscreenSize.getY( ) );
fl_begin_offscreen( d_offscreen );
// draw the widget hierarchy of this group into the offscreen
maxTreeContentScrollWindowGroup->redraw(); // tree panel drawing
fl_end_offscreen( );
// copy the offscreen back onto this window...
fl_copy_offscreen( 0, 0, offscreenSize.getX( ), offscreenSize.getY( ),
d_offscreen, 0, 0 );
} else {
GUImaxtreePanelWidgets::draw( ); // standard drawing
}
}
..
}
The point here is: is my complex widgets hierarchy held by
maxTreeContentScrollWindowGroup really redrawn? or does redraw() do something
else?
another question is: how can I access the bitmap/pixmap held by the offscreen?
so far is fl_copy_offscreen copying back to the screen, but I'd like to copy
such a bitmap to some library like libpng to save it to a file, but the real
data structure is hidden ... the Fl_Offscreen turns out to be a ulong (why?),
so where is the real offscreen data?
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
