|
|
On 6/12/22 13:40 'melcher....@...' via fltk.coredev 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 see your points but why do we need another method? In the context
given above I would really do something equivalent to suspend/resume
before and after Fl::wait(0) but this can likely be done with existing
methods as Manolo suggested in the respective commit comment (unless I'm
missing something).
As Manolo wrote, adding
Fl_Surface_Device::push_current(Fl_Display_Device::display_device());
before Fl::wait(); and
Fl_Surface_Device::pop_current();
after Fl::wait(); would work.
The drawback would be that you would push another context on the stack
rather than popping first to go back to the previous context and return
to the printer context after Fl::wait().
So, to answer the "other" question: if we added such new methods I'd
suggest to `pop` the drawing context in `suspend()` and `push` the
printer context in `resume()`. This would make these methods independent
of the "previous" context - which would be very likely but not
necessarily the "display" context.
I have no idea how to implement such a `resume()` method that would push
the pre-existing printer context back on the stack but I guess Manolo
would know?
--
You received this message because you are subscribed to the Google Groups "fltk.coredev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkcoredev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkcoredev/5240d6de-d4c7-277e-6571-eaeaf01f42b9%40online.de.
[ Direct Link to Message ] | |
|
| |