Hi
> > This is one of the points I don't get: I first create a
> > window and then I show it, isn't this just enough to have a
> > window mapped?
>
> No - that's not a safe assumption. It is generally the case these days
> that the actual rendering will occur pretty much asynchronoulsy (even
> more so now that we all have multi-core CPU's calling fancy accelerated
> GPU's) so a lot of the low-level OS calls (on X11, win32 or OSX) will
> return execution to your program a long time before they actually action
> your requesrt... Add to that the way fltk deliberately decouples
> rendering from the code sequence, or X11's remote abilities and etc...
> Well, lets just say that when your code returns from a window->show();
> call, you can be pretty sure your window is not actually mapped yet!
indeed, I wasn't considering the different threads ... the graphic one and my
program's one
> > or maybe I should force the window creation by Fl::flush() ?
>
> That'll do it, certainly, but that seems to me like a workaround.
I'm trying to get to work a small program using the offscreen and as less
possible fltk stuff, just to see what I really need to add to my real program.
I tried with Fl::flush(), but this doesn't actually work ... still segmentation
fault.
> > And a more fundamental remark is: why isnn't such a offscreen
> > totally independent of the widgets, visualized or not?
>
> The assumption is that whtever you draw in your offscreen you will, at
> some point, want to blit into a view, so you need to know the format of
> the view to be able to make a compatible offscreen context.
> Ideally this wouldn't be necessary, but we need to be cross-platfom
> compatible, so we have a bit of a lowest-common-denominator thing going
> on here.
I don't know all the details about being cross-platform, but I think it could
be useful to have a kind of "virtual" drawing, therefore abstracting away from
the whole graphics pipeline.
> > Aha, I see. well, this looks to me as a workaround.
>
> In what way?
Well, if ideally no fltk window would be needed to set up & use the offscreen,
setting up a window and so on is just to satisfy the dependancy from the
context of the offscreen handling. so this way we work around this dependancy.
just that.
> > Is this the only way to go? I already developed a quite complex
> > system, It doesn't feel right to manipulate again the
> > callbacks of my already complex widget structure ...
>
> Probably not the only way, but it is effective and straightforward.
> But I do not know your code, so YMMV.
> I confess I do not understand why this change would make much, if any,
> diference to how your widget callbacks operate.
Well, I draw a graph of (nested) widgets dynamically: depending on the size of
the graph, I add and put in the right position a Fl_Group containing a button
with an image, another couple of buttons and a text output field. all this
generated with fluid.
I'm afraid of the need to derive a class from every single widget of this group
just to hack in the offscreen ... I hope to find a more elegant way.
> > I'm analyzing your example now, indeed there was just that
> > example from Lukasz in the general forum.
>
> OK - hope it makes some sense! I left out the comments...
Right now I have a minimalistic window where I try to draw just a black square
in the middle.
the offscreen handling is called from the draw() function, but either I get a
fully black window, or a gray one. See the code below.
#include <iostream>
#include <string>
#include <FL/Fl.H>
#include <FL/Fl_Window.H>
#include <FL/Fl_Box.H>
#include <FL/fl_draw.H>
#include <FL/x.H>
#include <FL/Fl_Double_Window.H>
Fl_Offscreen offscr = 0;
int offscrW = 200;
int offscrH = 200;
void drawOffscreen( Fl_Double_Window *aWin ) {
std::cout << "drawOffscreen( Fl_Double_Window *aWin )" << std::endl;
std::cout << "*aWin is " << (aWin->shown( ) ? "shown" : "not shown") <<
std::endl;
int x = aWin->x( ); int y = aWin->y( ); int w = aWin->w( ); int h = aWin->h(
);
std::cout << "aWin x=" << x << " y=" << y << " w=" << w << " h=" << h
<< std::endl;
fl_begin_offscreen( offscr );
std::cout << "Fl_Offscreen OPENED" << std::endl;
fl_color( FL_BLACK );
fl_rectf( 0, 0, w/2, h/2 );
fl_end_offscreen( );
std::cout << "Fl_Offscreen CLOSED" << std::endl;
fl_copy_offscreen( x, y, offscrW, offscrH, offscr, 0, 0 );
std::cout << "Fl_Offscreen COPIED" << std::endl;
}
class MyWin : public Fl_Double_Window {
protected:
void draw( ) {
std::cout << "MyWin::draw()" << std::endl;
// Fl_Double_Window::draw( );
drawOffscreen( this );
}
public:
MyWin( int a, int b, char const *label = "Fl_Offscreen test" )
:
Fl_Double_Window( a, b, label ) { }
};
int main( ) {
Fl_Double_Window *aWin = new MyWin( 400, 400, "Fl_Offscreen test" );
aWin->resizable( );
aWin->show( );
std::cout << "Fl_Double_Window started" << std::endl;
offscr = fl_create_offscreen( offscrW, offscrH );
std::cout << "Fl_Offscreen created" << std::endl;
return Fl::run( );
}
This program just produces either a black window if Fl_Double_Window::draw( )
is commented out, or a grey one otherwise.
I'm pretty unsure about how to use fl_copy_offscreen, but maybe my mistake is
elsewhere ... why don't I get a nice black square in the middle of the window?
thanx,
Fabio
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
