[fltk.general] Re: Can custom box type functions handle their own high-DPI screen scaling? - Forums

Thank you, but this shows the problem I was referring to. The green button's top and right borders are 4px thick, while its left and bottom borders are 2px; the blue and orange buttons have uneven borders inconsistent with orange; and so on.

Ideally for me, at 200% DPI a boxtype function could disable having its own draw calls scaled, and instead multiply its own X/Y/W/H arguments by screen_scale(), so it would be like drawing a box twice as large and with a doubled offset from (0,0). (Then it would decide whether to, for instance, draw some of its elements as thicker or not.)

On Wednesday, February 24, 2021 at 1:24:55 AM UTC-5 Manolo wrote:

On Tuesday, February 23, 2021 at 4:54:14 PM UTC+1 remy.o...@gmail.com wrote:
Some months ago I was testing FLTK 1.4.x's screen scaling support in Windows. It worked as expected, with FLTK_SCALING_FACTOR or Fl::screen_scale() affecting the whole program's scaling, without my needing to manually adjust coordinate and size values.

I didn't continue with it because it was scaling lines in an ugly way, particularly at uneven scaling factors like 1.5. …

Hi Remy,
I would suggest you try again with FLTK 1.4 in its present state. The code has been much improved and
supports now all scaling factor values for color gradients. I attach an example given by the "unittests"
FLTK test program scaled at 170% on Windows. The situation is the same under Linux and macOS.