It looks like OF doesn’t know how to detect HiDPI displays on Windows. It’s been a while but I remember it not being too complicated to get this working on MacOS, the last time I tried (a couple of years ago).
Digging around a bit, it sounds like GLFW has added support for scaling detection on windows via the glfwGetWindowContentScale function. I spent some time hacking around in the ofAppGLFWWindow.cpp file, and as described, I was able to detect the DPI scaling of the display (as a float value) and use it to set the pixelScreenCoordScale. This let’s OF know we have a high resolution display, and I could see some scaling aware UI elements (like ofxDatGUI) were now displaying at the scaled-up resolution I wanted. However the window size itself was now the wrong size as well as a number of other measurements like calculating the display width. (I think this is still a difference between OSX and Windows)
Still, I think with a little bit of work, we should be able to get HiDPI support working in visual studio.
thanks for the info.
just FYI, Not long ago, a PR I made got merged in which I added some functions to properly scale ofxGui when using HiDPI screens.
I will try and take a look at that GLFW function. Looks promising.
@hrs - Yes, I am one of those people trying to leave the Mac ecosystem. Although I actually originally started out on windows almost 10 years ago (using codeblocks), moved over to mac, and have been trying to move back for a while now.
@roymacdonald - cool I will take a look at that. from a a quick glance at the PR, it looks like the scaling is set manually by calling a function. The other gui library I was looking at (ofxDatGui) was asking for the scaling as detected programatically using getPixelScreenCoordScale(). I’m not sure which approach is preferable - forcing scaling explicitly, or detecting it. Possibly one could want both options.
I’ll try to set up a test branch that will expose the windows display scaling value through the getPixelScreenCoordScale() method. That way the usage will be consistent between Mac and Windows.
a couple things to keep in mind:
Most of the code I’ve looked at treats the scaling value as essentially boolean - things are either rendered at 1x or 2x. At least on windows, display scaling is a floating point value (usually in increments of .25x - like 1.5, 1.75, 2.0, etc)
There is some other difference between Mac and Windows with the way they handle the scaling that Mac has a different ratio between the framebuffer size and the window size. This is causing a bunch of other stuff to break when I set the display scaling beyond 1 on Windows. Shouldn’t be too hard to fix, but I still need to work on it.
Hi, I’ve been using a Mac my whole life (yes, from the very first Macintosh) yet I have to work a lot on Windows and from some years now I’ve felt that apple is doing things the wrong way so I might eventually move out of the Mac ecosystem, but that’s a whole different story.
From the last time I used ofxDatGui, which was not that long ago, scaling had to be “manually” activated.
I think that it is a very useful thing to be able to set it both automatically (like programatically detecting if a hi res display is in use) or manually. What I think that should be done is to have an OF function that returns a bool which tells if the screen is hi res or not and based on that activate the scaling. At least on the PR I made there is a scaling factor, which is hard coded to 2 right now but all the maths are being done in accordance to it, so having a different scaling factor will not be a problem, as well as having a function for setting it.
@arturo do you think that I should add the option for setting the scale factor to other than 2? It should be an small and easy improvement. Are there any plans for adding an OF function that detects hi dpi screens? I could make that too.
this should detect the scaling factor and expose it through the getPixelScreenCoordScale() method.
I added a second windows only scaling variable, to avoid breaking all the calculations that are hard-coded into ofAppGLFWWindow where it assumes that the framebuffer size is not equal to the window size (as is the case on mac). The only thing this code should change is the external method to expose the scaling factor.
Also relevant background info about windows display scaling and glfw: