unexpected behavior when using Fl::use_high_res_GL(false)

[fltk]

unexpected behavior when using Fl::use_high_res_GL(false)

[ManoloFLTK]

That is unexpected. An FLTK app is expected to run correctly on a retina display
if it does not use the pixel_w() and pixel_h() functions provided it does not call
Fl::use_high_res_GL(1).
You can, if you have access to a mac, verify that with FLTK demo apps such as
cube or glpuzzle after commenting out their Fl::use_high_res_GL(1) statements and replacing
pixel_w() and pixel_h() by w() and h().

[ManoloFLTK]

Sorry, I didn't mean to close this issue.

[mtolly]

I have run into this on my own app -- it's a break in behavior when compiling on Catalina. A program compiled on prior macOS versions uses correct sizing, even when run on Catalina. Specifically the problem is in setting NSHighResolutionCapable to true (which is now also the default) but leaving use_high_res_GL disabled. If you explicitly set NSHighResolutionCapable to false the GL part draws okay, but the whole UI is not high-dpi.

SDL had the same problem, this is their fix: https://hg.libsdl.org/SDL/rev/46b094f7d20e

I am not a Cocoa/ObjC expert but I can see if I can try to put together a patch and test it soon. Otherwise if someone else wants to take a crack at it, I assume the right place to add the fix is here: https://github.com/fltk/fltk/blob/8a7d4c9/src/Fl_cocoa.mm#L2850-L2865

[ManoloFLTK]

@mtolly: the FLTK equivalent of what you show from SDL has been committed
to branch 1.4 on 26 october 2019 (d1e346a).
Thus, and for several other reasons, it's necessary to use FLTK 1.4 to build on
macOS Catalina 10.15.

[mtolly]

Ooh, thank you, I will give that a try. I was already using 1.4 but not quite the latest builds. Does that mean this issue can be closed, then?

[ManoloFLTK]

If @mtolly could confirm it's OK with the current 1.4 branch, I'll close this issue.

[ManoloFLTK]

Already solved.