Low DPI and wrong resolution in Mac OS X High Sierra.

[maeln]

I cloned and compiled Bonzomatic on my Mac OS X 10.13.3 and I noticed two bug:

• GLFW seem to use the wrong DPI (the title bar is very blurry).
• The resolution is wrong. A small resolution will end up creating a much bigger window.

Here is a screenshot.
I selected a resolution of 1440x900 which is much smaller than my mac resolution (2 880x1 800, 220dpi) and the window is bigger than my screen.

It seem to be related with this GLFW issue.
I tried to manually add :

<key>NSHighResolutionCapable</key>
<true/>

to the Info.plist of the App but the option "Open in low resolution" is still locked to true.

[maeln]

Ok, I found the issue:
You need to compile the mac version with the cmake flag GLFW_USE_RETINA and then add the thing to the Info.plist.

Do you think it's worth mentioning in the README.md in the "Build" section ? I can open a PR.

The font of the editor is still very aliased, but it's more a scintilla issue I suppose.

EDIT: Actually, the DPI seems to be still wrong. When I open it in fullscreen the text is super small and it make every other application opened on my mac the same.

[Gargaj]

@alkama all yours

[alkama]

Hello, there is a CMake flag to enable HiDPI build indeed, and no need to mess with the plist, it should produce the correct result.

Also note that GLFW 3.2 (current) has lots of glitches with (high) sierra in fullscreen mode. The current version doesn't respect the requested resolutions. There is an issue in GLFW repo i opened about it.

glfw/glfw#1047

Upcoming version GLFW 3.3 fixes a lot of those issues and will be merged here as soon as it's released.

Meanwhile, stick to using windowed mode, as was only available till not so long ago :)
And remember that in windowed mode, the requested resolution is in perceived resolution (as macos displays in the display settings) so when requesting 1440 width you get twice that on current mac laptops.

Or if you're adventurous, download the master branch of glfw and put it in the directory, and add the required flags and it should compile and work fine.

Last note: are you sure you want to code shaders on mac os using retina resolutions? I am amazed :) are you using a hackintosh?

[maeln]

Hello,
Thank you for the quick answer :) .
Adding the flag without messing with the info.plist will still make the title bar "blurry", but yes, the actual content of the window remain unchanged.
I will try to use the lastest git version of GLFW to see if I can use it like this for now.

[alkama]

Feel free to use that meanwhile:
https://alkama.com/drop/Bonzomatic_MacOS_GLFW33.zip

And btw, try to clear your build folder and start from scratch with no cmake cache to build the project with the retina flag. Here it does the trick. I have seen some issues where changing your mind while toying with this flag didnt produce result unless you did a true clean build.

[maeln]

As far as I can tell, it produce the same result on my mac.
But the problem might be elsewhere since it doesn't event seem to be using the font that you put in the config.json.
I am going to take a look to see if it doesn't come from my machine specifically.

[sacredbanana]

I don't know if this is related but if I choose 1920x1080 in full screen mode if Bonzomatic is launched from Xcode it doesn't display properly. If I launch Bonzomatic normally it works fine though. Dont know why launching from Xcode would be different.

[nkaretnikov]

@alkama how did you compile your version? with your version, i had to change NSHighResolutionCapable to true in the plist. otherwise, the menu/fonts were blurry. with the plist setting, everything looks fine. the only issue is that my mouse selection is weird: the selection area seems to be offset from the cursor by a few hundred pixels. also: the config doesn't seem to respect the skipSetupDialog setting -- seems to be an older version.

i've tried building from upstream and doing cmake -DGLFW_USE_RETINA=1 -DCMAKE_BUILD_TYPE=Release ../, then doing the plist thing, but it doesn't produce the same result. instead, i get weird resolutions and no text shows up (not a font issue as it works fine in the other version). i wonder what's different.

[alkama]

@nkaretnikov the version I compile forcefully disables Retina support because I dont want 4x larger framebuffers than I request, especially not on mac (considering their GPU). Blurry UI elements like title bar is what comes from disabling it.
For the courageous people that want HiDPI reenabled, there's a CMake option that takes care of GLFW part, and the template plist file can be changed for the NSHighResolutionCapable field. But last time I tried, on Mojave and Monterey, going fullscreen on HiDPI was completely broken, requested resolution was not provided and framebuffer goes berzerk being either partly offscreen or incorrectly stretched. Since it happens only on newer macos whatever the GLFW version, I tend to think it's a bug there. My debug-printing of "obtained framebuffer sizes" compared to standard requested ones shows totally random numbers.

[nkaretnikov]

@alkama fwiw, i don't use fullscreen with the high-res mode enabled because it's messed up indeed. i just tailored the dimensions to match my resolution and do not tick the fullscreen checkbox.

it's not just ui elements like the menu. my main reason for using high-res is font rendering. it looks like it's not aliased at all or maybe expects to be rendered on windows, not sure. e.g., symbols like "v" are not smooth at all. i've tried using bitmap fonts targeting low-res too (like the proggy family), but it's still not good enough

[nkaretnikov]

eg here's a version with high-res enabled and another one w/o. the fonts/builds might be different, but i think it still illustrates the point

and no, fiddling with the font size doesn't really help it

no high res:

alkama's build with high-res in the plist:

[alkama]

@nkaretnikov you might want to open the console or launch Bonzomatic from a terminal to see the log lines about "requested framebuffer" and "obtained framebuffer" sizes.

They come from https://github.com/Gargaj/Bonzomatic/blob/master/src/platform_glfw/Renderer.cpp#L305-L311

It might reveal some big difference between hiDPI vs non hiDPI support.
Especially considering the fragment shader will run for every pixels of the obtained framebuffer!
With retina support, I observed that when requesting fullhd, instead of having 1920x1080 pixels, I often obtained 3840x2160 instead, which lead to vastly different performance when livecoding :D