FLTK logo

Re: [fltk.coredev] RFC: using Fl_Printer in longer operations

FLTK matrix user chat room
(using Element browser app)   FLTK gitter user chat room   GitHub FLTK Project   FLTK News RSS Feed  
  FLTK Apps      FLTK Library      Forums      Links     Login 
 All Forums  |  Back to fltk.coredev  ]
 
Previous Message ]New Message | Reply ]Next Message ]

Re: RFC: using Fl_Printer in longer operations Albrecht Schlosser Jun 13, 2022  
 
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 ]
 
     
Previous Message ]New Message | Reply ]Next Message ]
 
 

Comments are owned by the poster. All other content is copyright 1998-2024 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to 'erco@seriss.com'.