fltk - High DPI.

[aditya siram]

Hi all,
I noticed that FLTK doesn't behave correctly in High DPI environments. I found a recent blog post suggesting a workaround: http://www.oyranos.org/2016/01/high-dpi-with-fltk/.

It would be really helpful if, as the post suggested, FLTK didn't just default to 96dpi on Linux and if there was global toggle that switches an FLTK app from absolute to relative fonts/dimensions. Does anyone know of any work in this direction?

Thanks!
-deech

[Martin McDonough]

That's interesting. FLTK does have some high DPI support, it works on OS X. I'm not sure if in that case it's just doubling all dimensions, though.

[Manolo]

On Wednesday, 8 June 2016 18:16:55 UTC+2, Martin McDonough wrote:

That's interesting. FLTK does have some high DPI support, it works on OS X. I'm not sure if in that case it's just doubling all dimensions, though.

On OS X, drawing units differ from pixel units for high DPI displays (so-called retina) whereas they coincide for classical density displays.
On a retina display there are 2 pixels behind one drawing unit (and 4 in a 1x1 rectangle).
Thus, most drawing code is unchanged. For example, the system draws high resolution text on retina displays, without the calling program
having to change the font size. For FLTK, it is enough to detect when a window is moved between displays of distinct resolutions,
and to trigger window redraws when it happens.

Most, but not all.

As far as FLTK is concerned, drawing of converging horizontal and vertical lines must be done differently on retina and other displays:
lines are one pixel (or half drawing unit) too short on retina if the standard drawing code is used. Thus FLTK draws those lines
slightly differently on retina vs non-retina displays.

Also, image drawing is done better when the image drawing size is considered differently from the image pixel size:
a larger number of pixels can fit in a given drawing area if it's on a retina display.
That's why Fl_Shared_Image::scale() is interesting under OS X also for display drawing, not only for printing.
FLTK draws images using a system call that maps part of an image, in pixel units, to part of the drawing scene, in drawing units.
On retina, the image pixels can fill the drawing scene at high resolution if they are numerous enough.

[Manolo]

Hi,
could you, please, apply the attached highdpi.patch to FLTK 1.3.3,
compile a test program calling Fl::screen_dpi(&dpih, &dpiv),
and report whether you obtain correct dpi values when run on a high DPI display?
Thanks in advance.

[aditya siram]

Yes, that worked!
Thanks!
-deech

[aditya siram]

I assume this is just test code, but should there be a corresponding `dlclose(...)` as well?