On Sunday, 12 June 2022 at 12:40:40 UTC+1 Matt wrote:
I added a comment yesterday: https://github.com/fltk/fltk/commit/bcbdf5546f53afdc0e3a4bb7458eb863783e76fd
and it's probably not the best solution.
When a print operation takes longer for whatever reason, and some other FL graphics may be rendered between a begin_page() and end_page() - a progress dialog, for example - the progress dialog rendering is sent to the printer not the screen.
I know that this is a very uncommon case, so I would like to ask the core devs how to solve this:
a: ignore, probably nobody (besides me) will ever have this issue
b: keep the doc changes to first pop the printer context, then push the context
c: change docs to first push the screen context, then render on screen, then pop back to the printer context
d: add a suspend() and resume() method that does b: or c: (which one)
Example:
myPrinter->begin_page();
while (!done) {
draw_part_of_page(); // slow operation
Fl::wait(0); // keep the app responsive, also flushes drawing requests
}
myPrinter->end_page();
So d: would add myPrinter->suspend() before , and myPrinter->resume() after the Fl::wait(0) statement.
I've never actually hit this, but I can see the point. As a solution for this case, option (d) seems sensible to me as it makes the operation explicit.
How suspend() and resume() should operate, in terms of popping/pushing the printer context and/or the screen context I do not know - I have no intuition about how that would best be achieved.
I guess Manolo is best placed for that call?