On 17.03.2010,a t 22:22, Matthias Melcher wrote: > On 17.03.2010, at 21:53, manolo gouy wrote: > >> Matt: >> >> I've just committed Albrecht's patch that in my hands is necessary >> and sufficient to force loading of Fl_Gl_Device_Plugin when >> fltk_gl is loaded, and thus to have Fl_printer::print_widget() >> print correctly GL windows on MSWindows. Checked that the cube and >> glpuzzle demos work well under MSWindows.
Manolo, I can confirm that your modification of my patch (with the additional FL_EXPORT keyword) does the job for me on Windows 7 with Cygwin/MinGW(GDI), Cygwin/Cygwin(X11), and Linux(X11). I didn't try MinGW directly yet, but I assume that this will work as well. >> I have also sorted out how to capture a GL window obscured >> by the print dialog window. Seems to work, although I don't see *why* it works. This is the double Fl::check() with redraw() of the top level window in svn r7290, isn't it? >> Could you, please, see if this is a good patch, and clarify why >> Albrecht does not get correct GL printing in his msys build ? > > Not much time tonight :-( > > This all must be an overzealous linker trying to optimize much more than it > should. Matthias, I don't think so. The problem is that the current module (Fl_Gl_Device_Plugin.cxx) does not contain anything that *needs* to be linked in to the executable (with static linking). Thus, it is simply not linked, and thus the plugin does not exist in the executable. In previous versions (up to 7080) it was in another file, together with Fl_Gl_Printer (IIRC), and this was linked in because we referenced Fl_Gl_Printer. > The plugins work like this: > > even before main() is called, all global variables are initialized. This must > be done for *every* global class. In the last line of > Fl_Gl_Device_Plugin.cxx, I instantiate such a global class: > > static Fl_Gl_Device_Plugin Gl_Device_Plugin; > > Maybe the "static" keyword confuses the linker, thinking that simply because > the class is not used, that it's not needed - which of course is wrong, > because instantiating the class creates an entry in a RAM based preferences > database for later access. Our function "print_gl_window" is called by the > plugin. So as long as the plugin is not "optimized" out, the function > shouldn't be either. See comment above and below. > So on Linux and MSWindows, please remove the "trick" as well as the "static" > keyword and let me know if this now works. Without the "trick" it doesn't work, neither with nor without the "static" keyword (no surprise, since it is not linked in, see above). The "trick" used is *only* to generate a reference that lets the linker link in the object module, so that the static plugin initialization can take place. [ I guess that this would not be necessary if we link dynamically and force the module to be in the shared lib / dll, but this must be forced as well. ] > Fl_Plugin should create this: > > // before even main() is called: > Fl_Plugin: creating a plugin, class "fltk:device", name > "opengl.device.fltk.org" > Fl_Plugin: creating a plugin manager for class "fltk:device" > Fl_Plugin: adding plugin named "opengl.device.fltk.org" at 0x0x175314 > Fl_Plugin: deleting a plugin manager The above does not happen without the "trick" (static or not). > // as soon as the window is printed > Fl_Plugin: creating a plugin manager for class "fltk:device" > Fl_Plugin: returning plugin named "opengl.device.fltk.org": 0x0x175314 > Fl_Plugin: deleting a plugin manager > > // when quitting the app > Fl_Plugin: deleting a plugin That's okay (with the "trick"). Without the trick (on Linux): $ test/cube [ comment: initialization part missing. The following happens when printing: ] Fl_Plugin: creating a plugin manager for class "fltk:device" Fl_Plugin: no plugin found named "opengl.device.fltk.org" Fl_Plugin: deleting a plugin manager Fl_Plugin: creating a plugin manager for class "fltk:device" Fl_Plugin: no plugin found named "opengl.device.fltk.org" Fl_Plugin: deleting a plugin manager Thus, I think the only solution is to create a real reference to a variable in this object module or to add another function that is called elsewhere. Another solution would probably be to put those about 120 LOC from Fl_Gl_Device_Plugin.cxx in Fl_Gl_Window.cxx (or to #include that file there), and that's it. ;-P Albrecht _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
