[fltk/fltk] The case for Fl_Window::pixels_per_unit() and Fl_Double_Window::pixels_per_unit() (#230)

FLTK matrix user chat room
(using Element browser app)   FLTK gitter user chat room   GitHub FLTK Project   FLTK News RSS Feed  
  FLTK Apps      FLTK Library      Forums      Links     Login 
 All Forums  |  Back to fltk.issues  ]
Previous Message ]New Message | Reply ]Next Message ]

[fltk/fltk] The case for Fl_Window::pixels_per_unit() and Fl_Double_Window::pixels_per_unit() (#230) Jay Oster 15:16 May 08 top right image

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.

Direct Link to Message ]
bottom left image   bottom right image
Previous Message ]New Message | Reply ]Next Message ]

Comments are owned by the poster. All other content is copyright 1998-2022 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to 'erco@seriss.com'.