thank you very much! how only could i miss the function "fl_read_image"... thats the perfect solution. next time i will read the docs more carefully.
> > > > Ok. thanks for those links. but - i dont think that this will help me. > >=20 > > i have subclassed an Fl_Double_Window and written my own=20 > > "virtual void draw()" function, so that i can paint inside=20 > > that Fl_Double_Window using the simple draw methods provided=20 > > by fltk ( for example fl_line(..) ). > >=20 > > now i need to get access to that drawing somehow, so that i=20 > > can save it. > >=20 > > of what use should it be, if i attach a background image to=20 > > that window using "w->image(my_fl_rgb_image);" ? is the=20 > > attached image modified by / drawn over by the fltk draw commands ? > >=20 > > the question is: how is drawing stuff in fltk handled=20 > > internally? is it a stored list of draw-commands, or is there=20 > > an image-buffer that stores pixels, wich then get modified by=20 > > fl_line etc calls? if such an internal buffer exists, is=20 > > there a hacky / tricky / legal way to access it? > > OK - sounds like you probably want to use fl_offscreen instead then. You > create the offscreen context, and render to that as if it were your > normal window. Note that the offscreen can be selected and drawn to at > any time, not just during a "draw" method, so in some uses this is more > convenient. You can also composite multiple images here, or use a pixmap > as a background or etc. > > In your "draw" method for your displayed window, you just blit the > offscreen image into the window. > > And of course you can get a handle to the underlying data... > > > > Alternately, you can get a handle to the data for the current window by > using=20 > > uchar *fl_read_image(uchar *p, int X, int Y, int W, int H, int alpha =3D > 0); > > Either in your existing draw method, or by using > Fl_Window::make_current() elsewhere to set a given window "current" > whilst you read back its content. > > The difficulty with this approach is that (in some implementations) > fl_read_image() will literally read back from the screen buffer, so if > there are other windows or cursors or etc on the screen, they may get > into your grabbed image - in this case, using an offscreen for your > rendering my be better since the offscreen is obvioulsy private to your > application. > > > > > > > SELEX Sensors and Airborne Systems Limited > Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex= > SS14 3EL > A company registered in England & Wales. Company no. 02426132 > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** > _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
