{"action":"opened","issue":{"url":"https://api.github.com/repos/glfw/glfw/issues/919","repository_url":"https://api.github.com/repos/glfw/glfw","labels_url":"https://api.github.com/repos/glfw/glfw/issues/919/labels{/name}","comments_url":"https://api.github.com/repos/glfw/glfw/issues/919/comments","events_url":"https://api.github.com/repos/glfw/glfw/issues/919/events","html_url":"https://github.com/glfw/glfw/issues/919","id":196280282,"number":919,"title":"Make screen coordinate baseline relative to 100% scale factor instead of whatever scaling factor primary monitor is","user":{"login":"adambrown","id":411773,"avatar_url":"https://avatars.githubusercontent.com/u/411773?v=3","gravatar_id":"","url":"https://api.github.com/users/adambrown","html_url":"https://github.com/adambrown","followers_url":"https://api.github.com/users/adambrown/followers","following_url":"https://api.github.com/users/adambrown/following{/other_user}","gists_url":"https://api.github.com/users/adambrown/gists{/gist_id}","starred_url":"https://api.github.com/users/adambrown/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/adambrown/subscriptions","organizations_url":"https://api.github.com/users/adambrown/orgs","repos_url":"https://api.github.com/users/adambrown/repos","events_url":"https://api.github.com/users/adambrown/events{/privacy}","received_events_url":"https://api.github.com/users/adambrown/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":0,"created_at":"2016-12-18T15:04:54Z","updated_at":"2016-12-18T15:04:54Z","closed_at":null,"body":"On Windows 10 you can change the screen scaling factor per screen under display settings, \"Change the size of text, apps, and other items:\". GLFW attempts to compensate for this by making everything relative to screen coordinates in all the related glfw calls instead of using pixels, with the exception being the frame buffer.\r\n\r\nGLFW seems to be assuming (from my local tests) that screen coordinates are 1:1 (sc to px) in the primary display's scaling factor. Furthermore, GLFW does not seem to provide a way to query that scaling factor on any display.\r\n\r\nThe problem this causes is that it is essentially impossible to create a UI layout that stays a predictable size between machines with different scaling factors for their primary monitors.\r\n\r\nFor example, on my current workstation I have a 4k display at 150% scaling, and a 1080p display at 100% scaling. I happen to have the 4k display set to my primary display at this moment. Lets say I create a window at 1920x1080 and the window goes on the primary monitor first. I add a UI element (it's a button row) that's 48sc units high and 1080sc units wide. Because my primary monitor is at 150% scaling this window appears at about the size a 1280x720 window would appear on a 100% scaling display of roughly equivalent dimensions. The button row appears as if it were 32px on a 100% scaling display.\r\n\r\nNow, if I move the window onto my 1920x1080 100% scaling monitor the window is downscaled by glfw and the window is actually drawn at 1280x720. The button row is drawn at about 32px and the sizing stays relatively consistent. All seems to work fine, and if that was the end of the story the system would work. In this scenario a screen coordinate unit appears to be roughly 0.6666666 of a pixel at 100% display scaling.\r\n\r\nThe problem arises when I change my primary monitory to my 1920x1080 100% scaling monitor. Note that the same thing happens if I go to another machine that doesn't have a 4K display and only 2x 2560x1440 100% scaling monitors so it's really a general problem. Now when I create the same window as above on the primary monitor it appears exactly as it would if it were a 1920x1080 window on a 100% scaling monitor (because it is). The button row now appears to be 48px (because it is).  The size appears consistently across the larger 150% display and everything looks 1.5x as big as it did when my 150% scale display was my primary. In this scenario the screen coordinate unit appears to be roughly 1.0 of a pixel at 100% display scaling.\r\n\r\nThis means I can build a UI that is the right size on machines with 100% scaling primary display, but it will be too small on machines with 150% or 200% scaling displays. Or I could build it the right size for a 150% scale monitor and it will look too small on retina displays and too big on old displays (this is what I actually did since my monitor is 150% and I didn't realize GLFW was doing it this way at the time).\r\n\r\nThe best solution would be if GLFW made screen coordinates always relative to 100% display scaling regardless of the scaling factor of the primary display, and simply make the frame buffer bigger for higher scaling displays. So 1sc would equal 1px at 100% display scaling or at 150% display scaling 1sc would equal 1.5px etc. This is what WPF and JavaFX and others do. This way it's possible to make a consistent layout that scales with higher dpi devices but remains a relatively consistent size across all. It's necessary to provide a means to query the display scaling of the current device so that UI elements can be rendered with higher (or lower) resolution to the frame buffer as needed. Although if screen coordinates were a constant reference size to 100% then the scaling could be determined by width of window in sc divided by the width of the framebuffer in pixels.\r\n\r\nAlternatively if the best solution couldn't be done or was too much work. A simpler workaround would be to simply  expose a function to query the scaling of the current device so that we can rebase our own unit system to 1.0 at 100% by accounting for the scaling of the primary monitor and thus the scaling of screen coordinates relative to the scaling of the current device.\r\n\r\nHere is a blog post that talks about how JavaFX fixed it: http://news.kynosarges.org/2015/06/29/javafx-dpi-scaling-fixed/\r\n\r\nThe relevant quote is:\r\n> Java 8u60 removes this annoyance by implicitly scaling all pixel coordinates, as well as loaded images, to the current Windows DPI setting relative to the 100% baseline. This is exactly what Windows Presentation Foundation (WPF) and modern browser layout engines are doing, and it’s really a necessity for painless user interface development. \r\n"}}
{"actor":{"display_login":"adambrown"}}