This function exists on Fl_Gl_Window and the os-issues documentation has some information on this method: https://github.com/fltk/fltk/blob/64296707d9e9b38dd9addf655f9b0943a4c54a54/documentation/src/osissues.dox#L877-L880

At least on macOS, it appears that Fl_Double_Window needs this same method for windows with a CAMetalLayer.

The XY problem goes like this: I don't need a GL window because I'm not using OpenGL. I am using Metal. A double-buffered window works well for this, except Metal and "Retina" displays have the same issues as described in the doc: https://github.com/fltk/fltk/blob/64296707d9e9b38dd9addf655f9b0943a4c54a54/documentation/src/osissues.dox#L854-L875

Gaining access to the scaling factor (or pixel width/height as explained in docs) for Metal layers on non-GL windows would be very helpful for all the same reasons.

The same doc also describes that Fl_Window and Fl_Double_Window act identically on macOS: https://github.com/fltk/fltk/blob/64296707d9e9b38dd9addf655f9b0943a4c54a54/documentation/src/osissues.dox#L882-L885

FWIW, I have attempted to use Fl_Gl_Window with Metal, but it prints this message:

2021-05-08 14:52:24.555 minimal-fltk[88155:717115] CoreAnimation: setting `contents' on CAMetalLayer may result in undefined behavior

I don't know the details here, but it looks like a conflict between the Fl_Gl_Window cocoa driver and my graphics stack which uses CAMetalLayer. So I'm ruling out Fl_Gl_Window as useful in my situation. It does support pixels_per_unit() though, and it also returns the expected scale factor that the app needs.

My other alternative is always assuming the scaling factor is 2. Works great on my MacBook Pro, but not so much on other platforms...

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.