Hello,
We are using your library in a ‘plugin like’ fashion within a host application, and it works wonderfully to abstract platform related complication.
I’ve recently run into an issue whereas the host app reacts very poorly to DPI scaling with our plugin in play, even if we dont create any windows, etc. I tracked this issue down to the fact that glfw is always calling one of the ‘SetProcessDPIAware’ related functions for win32. In this case, the host application has initialized it themselves and/or have shown a splash screen that breaks the Microsoft rule of ‘no UI can be created before calling these functions’.
I searched and found others have encountered this issue, and I can understand that glfw isnt inherently intended to be used in an embedded fashion. However, it works very well for this, and this DPI scaling issue is the only ‘showstopper’ I have encountered in our system.
I’ve locally created a branch of glfw and added a ‘GLFW_WIN32_PROCESS_DPI_AWARE’ hint, so that glfw only calls one of the ‘SetProcessDPIAware’ functions if that hint has been set. I left the existing ‘per window’ GLFW_SCALE_TO_MONITOR hint implementation unchanged. So far this seems to have worked very well for us and was a very small code change in glfw.
Is this something that would be accepted if I created a pull request for it? We would love to continue using the mainline code base vs maintaining our own fork and I’d be happy to setup the PR.
An additional argument for setting up this hint to make the calls optional, Microsoft actually recommends using a manifest file to set dpi awareness vs the API calls to avoid exactly these kinds of issues:
Note
It is recommended that you set the process-default DPI awareness via application manifest, not an API call. See Setting the default DPI awareness for a process for more information. Setting the process-default DPI awareness via API call can lead to unexpected application behavior.