On 13.07.2010, at 12:03, Domingo Alvarez Duarte wrote: >>> Probably pdf, postcript and direct printing will be executed as >>> background tasks or independent threads on some applications to don't >>> block the user interface but the actual implementation doesn't permit >>> it. >> >> I don't think that this is possible. FLTK's "Fl_Device-Philosophy" ;-) >> is that there is a static "current device" variable (among others). >> Therefore you can't do anything parallel to the main FLTK thread, >> because you would need to change the static variables... >> >>> Probably everything on fl_vertex.cxx should be non static members of >>> Fl_Graphics_Driver class, this way multithread using different derived >>> Fl_Graphics_Driver can work properly. >>> >>> Can this be made ? >> >> Independent of what I wrote before, such changes might be worth >> investigating, but they wouldn't help to make parallel printing >> possible, IMHO. Disclaimer: I didn't check the code so far... >> >> Albrecht > > Parallel printing is possible if there is no static data like the matrix > stack on fl_vertex.cxx, because we don't need a widget to appear on the > screen to print it, I'm currently use an fresh instance of Fl_Help_View > without any parent to layout the data and use > printer.print_widget(view_html) to print it and delete it after printing > (also the Fl_Help_View use some static data that should be moved to the > class instance), also forms created with fluid can be used to print > without showing then on screen.
That's all true so far... but it doesn't allow parallel printing and drawing on the screen, because there is (as noted before) only one rendering context that must be set up in some global variables. As you mentioned elsewhere, this is (among others) fl_graphics_driver. More specific: the printing context is set up when the Fl_Printer object is created or shortly after that with some initialization commands, and the Window drawing context is set up somewhere along Fl_Window::make_current() when called from Fl::flush(). All subsequent drawing goes to this device context, there's no way to use different device contexts in parallel threads. Please note that I read your proposal for changing the matrix and clip stack device specific, and that I agree that this would probably be useful anyway, but it doesn't help, unless the current graphics driver can be set up in another way than in global variables. > Static variables by individual virtual devices are less problematic than > global static ones, although still not a good solution. Yup, agreed. But that was the best we could do to introduce Fl_Device- specific drawing functions w/o adding a device context argument to each drawing function... AFAIK ;-) Albrecht _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
