Drawing on Retina or Higher DPI screen

[faejr]

Hello,

So I've been working with TurboBadger and after moving portable with my Macbook I realized that TurboBadger is not recognizing the higher DPI (and framebuffer) by GLFW and thus drawing on only half the screen. Have any plans been made or do you have any idea how to resolve this behavior in TB?

There is the glfw function glfwGetFramebufferSize that I did use and compared that with the requested pixel window size to get a scaling value, however with that I was only able to scale the root objects rectangle, which also appears to mess up some intersection logic with the cursor.

[fruxo]

The correct way to deal with it in TB is to just return the correct dpi from TBSystem::GetDPI. That will make dimension units (dp, mm) convert correctly, and also use the right skin graphics. All input is in pixels.

TBSystem::GetDPI is currently unimplemented for linux/mac since i haven't found any API for that in glfw. In windows it's semibroken (for backward compability you have to convince the win32 APIs that your app is "DPI aware" which will make the win32 api stop lying and tell the right DPI or something like that...)

I haven't looked into glfwGetFramebufferSize.

[faejr]

I did perform some testing and found that you could get the DPI here: http://www.glfw.org/docs/latest/monitor_guide.html#monitor_size

I did also notice that there was no Linux/Mac implementation at this time. But what I did notice is that when I changed the DPI, nothing was changed in the application except for graphics. The window was still 50% black at the time. I'd love to work with you to get a working Mac/Retina/DPI version of TurboBadger.

[codecat]

@LiljebergXYZ: I think in our case the buttons are sized by the images (the buttons are just using padding and the contents of our buttons are the images), so it would size the buttons dependent on the image size.

[mgerhardy]

There is a SDL backend pull request that implements the dpi handling.