Hi @MoAlyousef, thank you for the report and the demo program. I can reproduce the issue on my windows VM.

However, it looks as if this effect is caused by rounding errors and your usage of fl_rescale_offscreen() -- at least in my environment: my system (Windows) screen scaling factor is 125%, and this is my observation with your program:

• start program, draw by dragging: the canvas moves slowly to the right and produces artifacts (much better visible than in your screenshot)
• type ctrl/- once (FLTK displays "90%"): still artifacts
• type ctrl/- a second time ("80%"): no artifacts

Note that 1.25 * 0.80 = 1.00, i.e. 80% is equivalent to the native screen resolution and all other scaling factors are likely to suffer from rounding effects.

Note also that the printed scaling factor in the test code below is the "FLTK scaling factor" on top of the system scaling factor, i.e. it starts usually with 1 even if the system scaling factor is 1.25 (as in my case).

I assume you have a similar configuration on Windows which would explain the effect, right?

Questions (please answer independent of the solution below):

1. What is your system scaling factor on this Windows system?
2. What happens if you type ctrl/- once or more, does it change the behavior?

Solution: you should call fl_rescale_offscreen() only if the screen scaling factor changed WRT the previous draw() call. I fixed your demo program with code like this -- including test printf()'s which can be seen in my MinGW environment but maybe not if you compile with MSVC compilers. My proposed code changes (remove test statements):

// add this if you need fl_message() output (see below, commented out):
#include <FL/fl_ask.H>

// ... add this to the member variables:
  float scf; // scaling factor

// ... add the following lines at the end of the constructor:
    scf = Fl::screen_scale(0);
    // fl_message("scaling factor = %g\n", s);
    printf("scaling factor = %g\n", scf); fflush(stdout);

// ... change your draw() method like this:
  void draw() override {
    Fl_Box::draw();
    if (offs) {
      float s = Fl::screen_scale(0);
      if (s != scf) {
        // fl_message("scaling factor = %g\n", scf);
        // printf("New scaling factor = %g\n", s); fflush(stdout);
        fl_rescale_offscreen(offs);
        scf = s;
      }
      fl_copy_offscreen(x(), y(), w(), h(), offs, 0, 0);
    }
  }

This is simplified and works only on screen 0 (the first screen). My solution above is based on educated guesses (call fl_rescale_offscreen() only if the scaling factor was changed) and testing. It works for me with all tested screen scalling factors. I didn't look at the FLTK code though but I believe that @ManoloFLTK could tell if my assumptions are correct. Manolo?

Other than that it could be possible that the implementation of fl_rescale_offscreen() has a bug but that's also something Manolo would know better.

That all said, this issue doesn't look like a platform (Windows) issue, it's more like a "system scaling factor related" issue (at least if my assumptions are correct).

PS: independent of the given solution I suggest to use the new Fl_Image_Surface rather than the old fl_offscreen in new code.

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: <fltk/fltk/issues/475/1207454679@github.com>