Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DPI management impact in immediate draw #30

Open
deuxcents opened this issue May 16, 2021 · 0 comments
Open

DPI management impact in immediate draw #30

deuxcents opened this issue May 16, 2021 · 0 comments

Comments

@deuxcents
Copy link

Hello
In Windows, glfw will give: glfwGetWindowSize = glfwGetFramebufferSize, even if glfwGetWindowContentScale is not 1.

On other os you can indeed have glfwGetWindowSize = glfwGetFramebufferSize / glfwGetWindowContentScale like your are doing in void gs_platform_framebuffer_size(uint32_t handle, uint32_t* w, uint32_t* h)

So in Windows this is what happens when I ask with a Windows 150% scale factor:
gs_app_desc_t{
.window_width = 800,
.window_height = 600}
glfw creates a 1200x900 pixel window, this is fine
I draw an immediate 10 pixel square. It measures on screen 15 pixel in Windows. It will measure 10pixel on mac os x i suppose.
immediate set OpenGL viewport based on gs_platform_framebuffer_size which in windows will give me a viewport of 1800x900 exlaining the zoom of my square.

Question : should the user handle dpi on his side ?

If yes you should just call glfwGetFramebufferSize in gs_platform_framebuffer_size. For Camera2D maybe you need to call the framebuffer size instead of the window size (you need to think of all gs_platform_window_size calls).

One last thing : can you please add the glfw window create hint GLFW_SCALE_TO_MONITOR as a gs window option like GLFW_RESIZABLE ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant