GLFW and OSX retina display

[rougier]

There is a problem with window size on macbook with OSX retina display. For example, the ansi demo is rendered like this:

The problem comes from OSX that advertise "wrong" window resolution (half the actual pixel size).
See also #75

[adrianbroher]

What version of GLFW do you use? According to glfw/glfw#49 this is maybe a manifestation of a bug in an older version of glfw. Any version above 3.0.3 should contain a fix for this.

[rougier]

My version is 3.1.2

From 3.0 release notes (http://www.glfw.org/docs/latest/news.html):

GLFW now supports high-DPI monitors on both Windows and OS X, giving windows full
resolution framebuffers where other UI elements are scaled up. To achieve this,
glfwGetFramebufferSize and glfwSetFramebufferSizeCallback have been added.
These work with pixels, while the rest of the GLFW API works with screen coordinates.
This is important as OpenGL uses pixels, not screen coordinates.

I think the problem is that all demos set the window size in screen coordinates while the framebuffer size is still in pixels. The fault comes from OSX but the question is how to specifically solve this for OSX.

[adrianbroher]

Hm, well.

The demos in question uses the glfwSetFramebufferSizeCallback callback so it should get the pixel dimensions when reshaping. Can you add a print statement to the reshape function to verify this?

For example: the ansi window is resized to 800x500, the reshape function should then recieve 1600x1000 as dimensions.

I think the problem is that all demos set the window size in screen coordinates while the framebuffer size is still in pixels. The fault comes from OSX but the question is how to specifically solve this for OSX.

GLFW should already take care of that. If we use the framebuffer callback we should get the native pixel resolution, as the API already states multiple times. If it doesn't there is a bug in GLFW I assume.

[rougier]

Adding printf("Framebuffer size: %d %d\n", width, height); in reshape function gives me:
Framebuffer size: 1600 1000

However, what we really want is a framebuffer of size 800x500 because the demo has been written specifically for this size. If I set window size to (800/2, 500/2) it is ok. But we cannot request a specific framebuffer size using GLFW. The only hack I found (in another project) is to query the framebuffer size after window creation, to compute the ratio between window and framebuffer resolution and to resize the window accordingly.

[adrianbroher]

I'm sorry for not grasping the problem. Finally I understand your point. I completely ignored the fact that the orthographic projection doesn't fix the 'fixed resolution' creation of the text. So the solution is to either reduce the window size (like you suggested) or to increase the created output to honor the new resolution.

The only hack I found (in another project) is to query the framebuffer size after window creation, to compute the ratio between window and framebuffer resolution and to resize the window accordingly.

Well, I don't think that is a hack per se, but a correct way to fix this.

What do you think about the following solution?

adrianbroher/freetype-gl@c8474a9

It scales up the content by a factor calculated with the ratio between framebuffer and windows dimensions.

[rougier]

Your solution works but we would then need to do the same for all the demos and it might not be so simple for all of them.

What do you think about defining a consantt (RETINA_SCALING ?) in the cmake (default = 1.0) and multiply window size by this constant everywhere (0.5 in my case but I'm not even sure this is the same for every retina screen).

[adrianbroher]

Your solution works but we would then need to do the same for all the demos and it might not be so simple for all of them.

Well, then the solution will be complicated.

What do you think about defining a consantt (RETINA_SCALING ?) in the cmake (default = 1.0) and multiply window size by this constant everywhere (0.5 in my case but I'm not even sure this is the same for every retina screen).

According to the support pages users can set the scale factor to various values. I would prefer querying the value at runtime.

[rougier]

Ok, then we can use your scaling code to resize the window after creation. I'll try to do that by tomorrow.

[yairchu]

I think that if the windows will be resized to half the size then they would be really small, and make for less useful demos. It would be better if the demos would be able to work well at high pixel densities. I did notice that just increasing the viewport makes them render incorrectly, so I guess that each demo needs different small fixes.

[yairchu]

Note that some of the demos, like the ansi demo shown in the screenshot in the issue, are still not fixed.