GNOME Bugzilla – Bug 768081
Enable HiDPI support for GDK-Win32
Last modified: 2016-11-28 04:23:45 UTC
Hi, Some time ago we have added HiDPI support for the X11 and Quartz backends, and such support was not added to the GDK backend. This bug attempts to address the issue, so that we can aim for GTK -3.x apps to run with HiDPI support on Windows by default. With blessings, thank you!
Created attachment 330414 [details] [review] GDK-Win32: Make it DPI-aware Hi, This is most probably not ready for landing into master, as there are other parts that need to be dealt with. This is a very initial part of the work to do this, as the situation on Windows for HiDPI support is a bit different than on other platforms, as the DPI-awareness must be set very early on, otherwise the operation will not be allowed. An envvar GDK_WIN32_DISABLE_HIDPI is provided in case HiDPI support is undesired. I will post an image of gtk3-demo running with this feature enabled and disabled, to show the current progress. With blessings, thank you!
Created attachment 330415 [details] Current Status Hi, This image shows the current progress, where the HiDPI-enabled gtk3-demo is the one on the left, and the one with HiDPI support disabled is on the right. The main visible issue is that the icons become very very small, but the advantage is that the text and icons in the UI actually becomes much sharper, on my Windows 10 laptop with a HiDPI monitor. Will look more into getting the icons sized in a better way. With blessings, thank you!
Created attachment 330416 [details] [review] GDK-Win32: Make it DPI-aware (take 1.1) Hi, In the previous try, I left out the error check for the Windows 8 and below, so add that. I though perhaps I ought to organize the code a bit better... With blesings, thank you!
Review of attachment 330416 [details] [review]: Hey Fan, thanks for working on this. See the minor comments. ::: gdk/win32/gdkmain-win32.c @@ 160,3 @@ } gboolean _gdk_win32_enable_hidpi (void) gboolean in a different line @@ 182,3 @@ success = (SetProcessDPIAware () != 0); } return success; leave empty line before return ::: gdk/win32/gdkprivate-win32.h @@ 120,3 @@ PROCESS_SYSTEM_DPI_AWARE = 1, PROCESS_PER_MONITOR_DPI_AWARE = 2 } PROCESS_DPI_AWARENESS; Use came case ProcessDpiAwareness for example @@ 127,3 @@ MDT_RAW_DPI = 2, MDT_DEFAULT = MDT_EFFECTIVE_DPI } MONITOR_DPI_TYPE; same here
Review of attachment 330416 [details] [review]: Thanks for starting to work on this! Can the dpi of a monitor on Windows be any arbitrary number or is it a multiple of 96? I wonder since we will need to use that value to implement window_get_scale_factor and we assume it is an integer. If we set to PER_MONITOR_DPI_AWARE I guess the next step would be to add code to handle WM_DPICHANGED
Created attachment 330420 [details] [review] GDK-Win32: Make it DPI-aware (take 1.2) Hi Nacho, Here's the updated version with the issues you pointed out addresses, plus some minor cleanups and code layout improvements. Thanks! With blessings.
Hi Paolo, (In reply to Paolo Borelli from comment #5) > Can the dpi of a monitor on Windows be any arbitrary number or is it a > multiple of 96? I took a quick look at what happens in regards to WM_DPICHANGED... it does seem to me that a multiple of 96 is necessary for an integer value, as I could understand from this[1], because we need to divide the DPI by 96 for WM_DPICHANGED. > I wonder since we will need to use that value to implement > window_get_scale_factor and we assume it is an integer. > > If we set to PER_MONITOR_DPI_AWARE I guess the next step would be to add > code to handle WM_DPICHANGED. Yup, but this will only be possible on Windows 8.1 or Server 2012 or later. [1]: https://technet.microsoft.com/zh-tw/sysinternals/dn312083 p.s. The SetProcessDpiAware() call would be like what happens when we do SetProcessDpiAwareness(PROCESS_SYSTEM_DPI_AWARE). With blessings, thank you!
You've added enum declarations to GDK directly, but MSDN says that these are defined in ShellScalingApi.h Now, MinGW-w64 lacks that header, so declaring these things in GDK is absolutely fine by me, but that still doesn't explain why you're doing that on MSVC side. As for the patch, it is very simple, and looks correct so far. Speaking of icons, we need bigger gtk.ico (the RGB GTK logo icon). The one we have has largest size of 48x48. Should be increased to 256x256.
Hi LRN, Yes, I understand that these items are declared in ShellScalingApi.h, as stated in the MSDN site. I am glad that mingw-w64 does not have this header so that there is more justification that I defined the enum directly in GDK-Win32 :). The thing is, in order to support pre-8.1 SDKs (the header was added for the Windows 8.1 SDK), this enum declaration is needed, hence this was done on the Visual Studio side as well. This is also why LoadLibraryW() and GetProcAddress() was used for SetProcessDpiAwareness(), as this is only available for Windows 8.1 and later, so we need to acquire it at runtime on Windows 8.1 . The icon part, though, I think it is not that simple. In the .png that I put up, you might be able to see the minimize, maximize and close buttons being pretty small, as well as the arrows beside the demo items that have sub-items are very small as well, and the other part is that when the window opens upon running the program (which the image does not show), the window is quite small, and things seem to cram close together unless one makes the window bigger. Hope this explains the situation. Thanks for letting me know of the concerns here though. With blessings, and cheers!
About minimize/maximise/close icons - X-GTK handles this somehow, so W32-GTK should be able to do so as well. Maybe ask people who know the X side of things? About initial window size - that one is interesting. Again, we should look at how other backends handle this. That said, the most obvious way is to tell all widgets that they should multiply their size requests by N (they should already be doing something like that...maybe you're not setting some GDK variable or not calling some GDK function to change scale?). Doing this in the GDK backend would be messy, because there will be a huge code surface (internal GDK/GTK size, which is normal, VS external window manager size, which would be multiplied by N) to cover and converting back and forth would be very difficult to get right.
Created attachment 330429 [details] [review] Update GTK Windows icon (now scles up to 256x256) Try building with this icon, see if gtk-demo icon now look better on the taskbar.
Review of attachment 330429 [details] [review]: Hello LRN, (In reply to LRN from comment #11) > > Try building with this icon, see if gtk-demo icon now look better on the > taskbar. I needed to look close to the icon on the taskbar, but it sure does seem sharper to me! Thanks! I think we should get this in there by all means. I tested the current code on a non-HiDPI Windows 8.1 system and things did look and behave as before, which is more or less what I think we want to see. (In reply to LRN from comment #10) > About minimize/maximise/close icons - X-GTK handles this somehow, so W32-GTK > should be able to do so as well. Maybe ask people who know the X side of > things? > About initial window size - that one is interesting. Again, we should look > at how other backends handle this. It does seem to me that we need to look into implementing gdk_window_get_scale_factor() and/or gdk_screen_get_monitor_scale_factor() for these, they seem to stem from the same things. Could be very interesting work as you mentioned, but I think no messing around means no gain (pun intended) :). I will look into that tomorrow or so, getting late here though. Thanks again. > That said, the most obvious way is to tell all widgets that they should > multiply their size requests by N (they should already be doing something > like that...maybe you're not setting some GDK variable or not calling some > GDK function to change scale?). Right, but again we need to implement one or both of the aforementioned items in the backend so that setting that envvar really has some effects. Hence the patch for gdkmain-win32.c is really initial work... as advertised. With blessings, thank you, and cheers!
Created attachment 330472 [details] [review] GDK-Win32: Make it DPI-aware (take 2) Hi, I updated the patch for declaring GDK to be DPI aware, to: -Set a DPI-awareness flag for GdkWin32Display. -More tolerance for apps that choose to enable/disable DPI awareness via app manifests. -Move everything except the ProcessDpiAwareness enum into gdkdisplay-win32.[c|h], as the call to the APIs there are early enough, and we need stuff from GdkWin32Display eventually. With blessings, thank you!
Created attachment 330713 [details] [review] GDK-Win32: Make it DPI-aware (take 0.3) Hi, This is the current state of the HiDPI support on Windows, notable changes from the last patch: -Use a structure to hold the shcore.dll functions, to cache those function pointers we acquire -gdk_window_get_scale_factor is now implemented for Windows. No GDK_SCALE is used here though, and probably won't be used at all on Windows. -Now the "layered" windows launch at a much better size -We do support HiDPI/scaling when it is activated via application manifests or a suitable compatibility setting is used, since the manifest is the recommended method of enabling DPI awareness in apps (the adjustments in the "issues" below are still necessary though!) Issues to address: -Icons in the UI are tiny (please see image I will attach closely--see in particular the minimize, maxmize and close buttons to see this). -Non-layered windows (e.g. GL windows) are off. Need to find way to tell GDK to update the change. -Perhaps we still need a few layout improvements as well. -Show messages/warnings when one uses the GDK_WIN32_DISABLE_HIDPI with GTK applications with the manifests for DPI awareness used, or when a control panel/.exe setting is forced for DPI compatibility. The reason behind this is the these will force on (or off, depending on its settings) DPI awareness, which trumps over any use of GDK_WIN32_DISABLE_HIDPI or SetProcessDPIAware() or SetProcessDpiAwareness(). No pun intended here:)! With blessings, thank you!
Created attachment 330714 [details] Current status Hi, This shows the current status of this ongoing work. (In reply to Fan, Chun-wei from comment #14) > -We do support HiDPI/scaling when it is activated via application manifests > or a suitable compatibility setting is used, since the manifest is the > recommended method of enabling DPI awareness in apps (the adjustments in the > "issues" below are still necessary though!) Here, the "recommended" refers to what MSDN recommends, but hey, we are doing this in a lower level, so that the goal is to allow HiDPI support on Windows with and without the use of the manifests! With blessings, thank you!
Review of attachment 330713 [details] [review]: Minor nitpicks from my side, I'll let LRN to review the logic since he wrote most of that stuff.. ::: gdk/win32/gdkdisplay-win32.c @@ 913,3 @@ case DPI_STATUS_SUCCESS: GDK_NOTE (MISC, g_message ("HiDPI support enabled, type: %s", display->dpi_aware_type == PROCESS_PER_MONITOR_DPI_AWARE ? "per-monitor" : "system")); wrong align ::: gdk/win32/gdkdisplay-win32.h @@ 25,3 @@ /* Define values used to set DPI-awareness */ typedef enum _GdkWin32ProcessDpiAwareness { PROCESS_DPI_UNAWARE = 0, 2 spaces
Looks OK so far. Glad that GtkShowWindow() found another use :) That said, it seems to me that this does scaling one way (GTK asks the OS to change window size, GDK multiplies the size by window scale in between). How about the reverse (WM_SETWINDOWPOS etc)? Do we need to scale that as well? Is it already scaled somewhere? Just in case you haven't thought of that. Looking at X11 backend, i see that it multiplies/divides by scale factor basically *everywhere*. As for icons, i did some preliminary testing on Debian, and what you are observing on Windows looks very similar to what i was observing on Debian when running with GDK_DPI_SCALE=2.0 - Text is bigger, icons and widget elements (borders, scrollbars) are still small. On the other hand, running with GDK_SCALE=2.0 on Debian does produce the desired effect (everything is 2 times bigger). Another thing that i've been able to learn is that on Debian gtk_widget_get_scale_factor() returns 2 from the very beginning (if you look at the implementation, you'll notice that it has multiple branches, depending on whether the window is realized, or toplevel). While testing, i've discovered that a typo: > if (!win32_display->have_at_least_win81) should be > if (win32_display->have_at_least_win81) Also, you don't initialize is_scale_acquired, so when wrong condition is used, that variable might contain random values.c Also, looking at X11 backend, i see that it has separate scale factors for screens, monitors and windows. In practice they are often aligned, but it might be possible to make them different, if one tries hard enough. Manual overrides via environment variables probably help. Anyway, you're not calling gdk_monitor_set_scale_factor() at all, even though gtk_widget_get_scale_factor() depends on it (at least partially). That said, i did hack this function to return something other than 1, and i still don't get the expected result.
ebassi pointed out that we need to call cairo_surface_set_device_scale() on the surface returned by gdk_win32_ref_cairo_surface_layered(). I've hacked it to do so, and got the expected 2x size increase result.
Hi, (No new WIP patch at this point, sorry!) --- Hi LRN, Thanks for pointing out the typo, I forgot to change it back after testing for Windows 7-ish code paths. :| Perhaps I missed something, but going by the cairo_surface_set_device_scale() actually posed more problems than resolved... resize doesn't redraw on the spot, and gtk3-demo-application throws a bunch of warnings for "infinite surface size not supported" when launch repeatedly from gtk3-demo so I might need to set it aside. Thanks though. Did I understand you correctly? The window contents (texts) do look behaving the same as if no HiDPI is supported, which I understand should be the case. Anyways, currently what needs to be done, to sum things up: -Get the icon sizes right (the various icons from adwaita-icon-theme for the various parts of the UI, as shown in the image I posted a few days ago... Might need to look in Windows APIs to scale them better. -Still need to find out about the scenarios where window is not layered, such as GL windows, which the last attached image tried to show (via launching the GtkGLArea demo), albeit it might not seem that clear. -Handle WM_DPICHANGED for Windows 8.1 , as Paolo suggested. -See whether gdk_monitor_set_scale_factor() needs to be called more often. Currently I called it on the monitors I get from the GdkWindow's during gdk_win32_window_get_scale_factor(), but will probably need some more tweaking, as above for WM_DPICHANGED. --- Hi Nacho, Since this is ongoing work, I will need to look at the nitpicks a bit later, sorry. This most probably means at least I could find a solution that works well enough for the two issues above. Thanks though. With blessings, thank you!
(Did I understand you correctly? The window contents (texts) do look behaving the same as if no HiDPI is supported, which I understand should be the case...->should read: during resize, the window contents (texts) do ...) Sorry for the noise!
Created attachment 330858 [details] [review] Functions missing in old versions of MinGW-w64 SetProcessDPIAware() and IsProcessDPIAware() are missing in old (from April 2015) versions of MinGW-w64. This is a quick hack to make them runtime-loaded.
Created attachment 330859 [details] [review] Misc changes on top of DPI-aware patch 0.3 After calling cairo_surface_set_device_scale() everything becomes bigger (2x bigger for scale=2) - text, lines, icons (AFAICS; difficult to tell, as my hacks only made things 2x bigger without increasing the surface size -> i see only the left half of the window; but checkboxes and the top-left button in widget-factory are larger). To accommodate that, the actual surface size also has to be multiplied by the scale factor. "infinite surface size" does happen when scale is too big. It could happen when a variable is left uninitialized, and then scale is set to a random (large) integer. "gdk_win32_ref_cairo_surface_layered()" was a typo on my part. That was indeed the function that i've hacked on, but, obviously, *all* surfaces we create (in gdk_win32_ref_cairo_surface(), etc) need to have cairo_surface_set_device_scale() called on them. I'm not sure about window resizing. With my hacks, resizing is just resizing, everything looks as it should look. Anyway, what currently needs to be done: * Call cairo_surface_set_device_scale() on all surfaces that we create * Scale up everything we get from GTK by SCALE_FACTOR (GtkShowWindow() mostly covers that, but there might be other places) * Scale down everything with get from Windows Window Manager by SCALE_FACTOR (i.e. all WM_* that we get should have their width/height info divided by SCALE_FACTOR). * Call gdk_monitor_set_scale_factor() when initializing monitors, and call it when DPI changes. Some other thoughts: The GetDC/GetDeviceCaps/ReleaseDC thing - does it need to be done with the window handle? Can we use NULL (i.e. do this with the screen DC)? If yes, we should be able to make a gdk_win32_display_get_monitor_dpi (display, hmonitor, *dpi) function that either gets per-monitor DPI (newer versions of Windows) or whole desktop DPI (older versions). Of course, we could just give HWND as another argument, but then the function name becomes misleading (it doesn't mention a window, and i don't know how to fit it there). Also, we should support GDK_SCALE and/or GDK_DPI_SCALE (i think GDK_DPI_SCALE is for text only, while GDK_SCALE is for everything) environment variables to be able to override the whole desktop scale. This way we would be able to test this without actually changing the OS DPI settings. I'm attaching all of my changes (except for the missing functions patch) merged into one patch here. It's not release-quality, just a few quick hacks to see how various things work. You can run "GDK_SCALE=2 gtk3-widget-factory" to see the effects.
Created attachment 330903 [details] [review] GDK-Win32: Make if DPI-aware (take 0.4) Hi, It does seem that at this point cairo_surface_set_device_scale() does not do us too well here, as in HiDPI scenarios it does cause text blurness, slowdowns and stability issues, so I think we still need to look into other ways to scale the icons, perhaps using the Windows APIs (and, the GL windows do not show up properly yet). Text blurness is actually something we want to address on HiDPI displays in this drive here. So, this is the current progress, which: -Addressed the nitpicks, hopefully. I can't promise I can look at them very thoroughly until I get back to the non-0.x patches. -Have the DPI awareness functions from user32.dll acquired at runtime, so that older mingw-w64 can build and run the items here. I did the coding in Visual Studio 2008 :) -As a workaround, force window_scale=1 for GL windows. The GL window is smaller, but does show crisply on HiDPI displays. Not doing so would result in 1/4 of the contents shown in the window (see previous image), and the texts in there being blurred, which Also, still need to test and see how things work in the multi-monitor scenario, but at least things look a bit nicer now. With blessings, thank you!
Created attachment 330905 [details] Current progress (at take 0.4) .
Created attachment 330911 [details] How cairo_surface_set_device_scale(..., 2) looks nitpicks: * in 0.4 GDK_SCALE is applied only when process is *not* DPI-unaware. Why? I think it should work regardless (i.e. force DPI-awareness to be "one DPI for the whole desktop"). * You forgot to set has_fixed_scale=TRUE when processing GDK_SCALE * There's a useless g_return_val_if_fail (display != NULL, 1) check that checks uninitialized variable As for cairo_surface_set_device_scale(), *not* using it means that lines won't be thicker. If lines don't get thicker, we'll never get the same HiDPI experience that X11 users do. This makes me sad. I do not know why it affects the text rendering in a negative way for you. For me the text is being rendered normally. That said, i'm not running this on a HiDPI display (because i don't have one), nor do i change DPI settings of the OS - i'm only using GDK_SCALE=2. This might have something to do with it. As for slowdowns - yes, increasing GDK_SCALE does seem to make things slower. This might or might not be a cairo/pixman bug. Dunno what to do with GL, but it should, technically, work the same way as everything else, as we're still using cairo for rendering (but composite everything in the window using GL). I'm attaching a screenshot of a window with W32-GDK that has cairo_surface_set_device_scale() call hacked into it. It has all kinds of problems due to scale not being applied to incoming input, and only 1/4 of the window is being shown (window is actually too small), but it doesn't seem to be causing slowdowns, and text isn't blurry. Without cairo_surface_set_device_scale(), but with nitpicks fixed, running with GDK_SCALE=2 has no effect, except making the window bigger initially (but everything inside it is still rendered at normal size).
Created attachment 331397 [details] [review] GDK-Win32: Make it DPI aware (take 0.5) Hi LRN, (In reply to LRN from comment #25) > Created attachment 330911 [details] > How cairo_surface_set_device_scale(..., 2) looks > > nitpicks: > > * in 0.4 GDK_SCALE is applied only when process is *not* DPI-unaware. Why? I > think it should work regardless (i.e. force DPI-awareness to be "one DPI for > the whole desktop"). Well, using GDK_SCALE > 1 is going to look bad when DPI awareness is not enabled (blurry text), so I thought that it ought to be ignored--however I added a g_message() regarding it. Note that DPI awareness should always be enabled unless it is explicitly disabled via the app manifest or app compatibility settings. > * You forgot to set has_fixed_scale=TRUE when processing GDK_SCALE This fixes it. > * There's a useless g_return_val_if_fail (display != NULL, 1) check that > checks uninitialized variable This fixes it. > > As for cairo_surface_set_device_scale(), *not* using it means that lines > won't be thicker. If lines don't get thicker, we'll never get the same HiDPI > experience that X11 users do. This makes me sad. OK, this is now in the patch, and I figured it out to work better. > Dunno what to do with GL, but it should, technically, work the same way as > everything else, as we're still using cairo for rendering (but composite > everything in the window using GL). Still need to look further into this. This patch currently forces GL windows at GDK_SCALE=1, for the moment. > I'm attaching a screenshot of a window with W32-GDK that has > cairo_surface_set_device_scale() call hacked into it. It has all kinds of > problems due to scale not being applied to incoming input, and only 1/4 of > the window is being shown (window is actually too small), but it doesn't > seem to be causing slowdowns, and text isn't blurry. The window with this patch seems to be drawn properly now, and the mouse pointer input is correctly detected for the 1/4 of the window, so still need to find a way to get it to apply properly across the whole window. Another issue is that "about" windows become 2x of its previous size when opened more than one time, and menus can have extra white space (2x, ...) when the same menu isd opened for more than one time. With blessings, thank you!
Created attachment 331398 [details] Current status at take 0.5
Created attachment 332516 [details] [review] GDK-Win32: Make it DPI aware (take 0.8) Hi, Finally I managed to make some good progress here, so finally here comes a new patch for this drive. What was fixed: -Windows can be moved and resized properly, and menus launch and relaunch properly. -GL Windows display correctly. It turned out we must get the unscaled width and height for the windows for this, which corresponds to the items that Windows is expecting. The width and height that GDK gives must be scaled accordingly. -Mouse and scroll input are correctly handled, at the right spots and across the entire window, not just the top-left quarter. What remains to be done: -Test across multi-monitor scenarios, and to handle WM_DPICHANGED which is emitted on Windows 8.1 when the window moves between monitors. -Tweaks for AeroSnap -Tweak for menu positions. With blessings, thank you!
Created attachment 332517 [details] Current status at take 0.8 Hi, Here an image that shows what goes on now. With blessings, thank you!
Window resizing and moving is not handled with 100% correctness. For me the window jumps when moved (the relation between the grip point and the move distance is somehow incorrect) and jumps when being resized (same problem). I've also noticed the problem with menu positioning that you've mentioned. Otherwise it looks quite well. I've also concluded that my scalable icon patch does not have the effect that i wanted. The icon embedded into executables does look good when "Huge icons" mode is set in Explorer, but the hiDPI taskbar icon is still blurry. Will have to investigate further.
Actually, no, the icon is fine. Just had to log out and log back in. Apparently, a lot of DPI settings require that, and just killing all instances of explorer.exe is not enough to apply the changes completely.
Created attachment 333398 [details] [review] GDK-Win32: Enable HiDPI Support (take 0.8.5) Hi LRN, Thanks for letting me know how the work-in-progress works for you! (In reply to LRN from comment #30) > Window resizing and moving is not handled with 100% correctness. For me the > window jumps when moved (the relation between the grip point and the move > distance is somehow incorrect) and jumps when being resized (same problem). This should be fixed. > I've also noticed the problem with menu positioning that you've mentioned. This should also be fixed. > Otherwise it looks quite well. Thank you! The remaining items are now getting AeroSnap to work when GDK_SCALE > 1, and to test for multiple monitors on Windows 8.1 , which should actually put us in a better position than QT in regards to supporting HiDPI on Windows (they only enabled DPI awareness, but the other items aren't scaled up, as I tried in kdiff3 using QT 5.6) I won't be attaching an image of the current progress this time though. With blessings, and cheers!
Comment on attachment 330429 [details] [review] Update GTK Windows icon (now scles up to 256x256) Attachment 330429 [details] pushed as 09004b5 - Update GTK Windows icon (now scles up to 256x256)
Tested the attachment 333398 [details] [review]. Resizes and window moves are now handled correctly, menu is shown in correctly. Also noticed the abovementioned slowdowns (when resizing or doing animated page switchers on gtk3-widget-factory), but i think this is just cairo being slow, nothing we can do about it. Specifically, if i resize gtk3-demo window down to 1/4 of its original size (when GDK_SCALE=2), slowdowns are practically gone, which is what i expected, because 1/4 at scale=2 is the same as 1/1 at scale=1 There are some weird corner-cases (such as when resizing gtk3-widget-factory when Windows scaling is set to 200% and resolution is not high enough for gtk3-widget-factory window to fit into the screen), but, again, it's probably not a backend problem, and definitely not a problem of this patch. As for the patch itself, code-wise, the part where DPI is detected/enabled seems OK (we already went over it in previous iterations). Everything else is, basically, just a massive set of one-line "multiply or divide by scaling factor" changes. One thing i haven't tested is custom cursors. My default GTK loads Adwaita cursors (i have gtk-cursor-theme-name=Adwaita in settings.ini), and that works fine on normal DPI, but i have no idea how that is going to work in HiDPI scenarios. That remains to be seen.
Cursor selection works correctly. There was a problem with W32 cursor support in Adwaita, i'll file a separate bug for that. Once that is fixed, custom Adwaita cursors will have correct resolution when HiDPI mode is enabled, no changes to GTK are necessary.
Created attachment 334222 [details] [review] GDK-Win32: Enable HiDPI support (take 0.9) Hi, This is another patchset for enabling HiDPI support on Windows, where the remaining work is to handle WM_DPICHANGED, for multi-monitor scenarios, so this means that AeroSnap should now be working more or less well at this stage. It's not easy to get a screenshot to depict the current progress compared to the previous one, so I won't attach one here this time either ;) Note that due to Intel display driver problems for Intel Graphics 530 GL windows could crash on iconify/minimize (with or without HiDPI enabled--any advice to work around this would be great, I'm out of ideas for this one), and Intel drivers on Windows for OpenGL is not known to be good-behaving from time-to-time. With NVidia drivers the code works fine on two systems. --- Hi LRN, Thanks for letting me know about the current status of the Adwaita custom cursors! --- With blessings, thank you, and cheers!
GL stuff is a real bonghit. For example, recently i've discovered that all GTK GL windows suffer from severe rendering corruption, and that running any GTK application with GDK_GL=always spreads that to all windows and quickly ends in a crash (!). The culprit was the AMD Settings global setting where i've forced antialiasing to be "2xEQ". Turns out, any EQ antialiasing caused this for me. So yeah, weird things happen between GPUs, drivers and apps, on Windows - moreso. Sadly, i can't be of any help with that, as i don't do GL.
Hi LRN, (In reply to LRN from comment #37) Thanks for letting me know about this, I will try to take a look at that, most probably in another bug series--I could reproduce the crashes you had as well, with or without this patch here, when using GDK_GL=always. With blessings, thank you!
Created attachment 334774 [details] [review] GDK-Win32: Enable HiDPI (take 1.0) Hi, This is the current status of the work on HiDPI, which I think should be more or less complete, except that for multi-monitor scenarios, we need to figure out the positioning of the window when we move/resize it across monitors, and whether we need to resize the window when we move across monitors, both when the DPI scale changes (please see commit message--the scaling changes are however applied correctly during these two scenarios otherwise). I probably won't be able to work on this again until Sept. 19 due to travels, so if someone can review and/or complete the one or two missing pieces that I've mentioned above, it would be great. Thanks for all the help and feedback along the way. With blessings, thank you, and cheers!
Created attachment 337571 [details] [review] GDK-Win32: Enable HiDPI Hi, I think this is what I can have at this point, and it does seem that after some investigation that the window size is correct when we have a WM_DPICHANGED event sent. It does seem to me that somehow a configure event is forcing the window positioning during WM_DPICHANGED to go way off, so we might have to hold off fixing this until we see how the Wayland people are doing the per-monitor HiDPI support, it might require a change to GDK itself. If there are any ideas here, it would be great! Note that the positioning issue does *not* exhibit when GDK_SCALE is set. From research and findings on Firefox development, it also seems that we can't get a very accurate position of the cursor positioning with respect to the window positioning due to a system limitation.[1] Font wise, when scale is 1, we still use the original method, which is detected by Windows, but for 2 and above, we force the font DPI to be 96 via _gdk_screen_set_resolution(), which should make it: -in line with what happens on Linux, so we only scale up the fonts when GDK_WIN32_FONT_RESOLUTION is set. -Words don't go out of scale on the UI, which should make things a bit nicer. I think if it is alright maybe we could try to get this into mainline, so I think this patch set is open to nitpicks :). [1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1262398 With blessings, thank you!
Created attachment 337572 [details] Current status Hi, This is how the gtk3-demo looks at this point (HiDPI enabled, scale automatically detected at 2). With blessings, thank you!
As discussed on the IRC, i think that this patch should be safe enough for inclusion into master (though i'm not sure whether it's gtk3 master or gtk4 master...), as, AFAIU, it will not have any adverse effect on existing applications (you need a manifest or an explicit API call, or GDK_SCALE set to enable HiDPI).
Hi LRN, Did I understand you right--update the patch to activate HiDPI on-demand instead of by-default? Note that this patch series at this point does activate HiDPI support by default when the display supports HiDPI, without any changes to the application--as long as a manifest is not used to disable it or GDK_WIN32_DISABLE_HIDPI is not defined. So, if one updates to the latest GTK /GDK with this patch here, they would get automatic HiDPI support unless it is explicitly disabled by the manifest (or system settings), or the envvar, and the manifest/system settings will overrule the envvar. Note also that on HiDPI-capable displays, setting GDK_SCALE=1 still gives a clear and crisp GTK window on the display (although everything is smaller). Let me know, with blessings, thank you!
Ah, well, my mistake. I must have confused using HiDPI support on a HiDPI system with using HiDPI support on a non-HiDPI system. Anyway, the patch seems OK and working in essence. Now it's up to nacho to nitpick it a bit, then we should be able to push it and deal with any fallout as it happens.
Created attachment 338166 [details] [review] GDK-Win32 4.0: Enable HiDPI Hi, This is for the 4.x branch, for HiDPI support. I think, perhaps, if we want to add HiDPI aupport for 3.x, a conservative way is to use the per-process DPI Aware mode instead of per-monitor (the catch is that it will be more like the X11 situation except that the DPI scale from the primary monitor can be auto-detected, but we won't scale differently if the window is moved to another monitor that we get a different DPI/scaling factor), as the other parts should be working at this point. This patch will obviously depend on bug 773299 as things need to be ported to 4.x first for gdkwindow-win32.c. With blessings, thank you!
Attachment 338166 [details] is logically the same as attachment 337571 [details] [review] , just rebased to apply to gtk4. The sole exception seems to be in stash_window() function, from which unused arguments were removed. As long as it compiles and works, its fate should be the same as the fate of attachment 337571 [details] [review].
Created attachment 338498 [details] [review] GDK-Win32 4.0: Enable HiDPI (take ii) Hi, This is due to the removal of gdk_device_manager_get_core_pointer()... With blessings, thank you!
Created attachment 338674 [details] [review] GDK-Win32: Enable HiDPI Hi, I updated the patch for 3.x as: -The GL improvements patch in 773528 is likely due before this patch. -Updated formatting a bit. -It seems that it is better that we use PROCESS_SYSTEM_DPI_AWARE instead of PROCESS_PER_MONITOR_DPI_AWARE not only because it brings much lower impact on multi-monitor scenarios, and it does seem to me that we are over-smarting ourselves. The existing code in GDK (and GDK/Win32) seems to handle things much better than trying to handle WM_DPICHANGED ourselves during PROCESS_PER_MONITOR_DPI_AWARE. We may want to revisit PROCESS_PER_MONITOR_DPI_AWARE for 4.x, but probably it is best to forget about it for 3.x and set it aside for 4.x at least for the moment. I understand that 3.22 is the last and LTS (long-term support) for 3.x, but IMHO it would be nice that we can have HiDPI support for 3.x users. With blessings, thank you, and cheers!
Created attachment 338676 [details] [review] GDK/Win32/4.0: Enable HiDPI (take iii) Hi, Like in the previous comment, use PROCESS_SYSTEM_DPI_AWARE by default, and leave PROCESS_PER_MONITOR_DPI_AWARE available as an option when an envvar is set, due to the same reasoning, as currently using PROCESS_PER_MONITOR_DPI_AWARE we are trying to be too smart here, and GDK/GDK-Win32 already handles things alright when we move across monitors. Also rebase the code to the current state of master, and adjust the code format a bit. With blessings, thank you!
Created attachment 338888 [details] [review] GDK/Win32/4.0: Enable HiDPI (take iv) Hi, Updating the GTK -4.x patch to: -remove extra spaces in empty lines -deal with the patch in bug 773299 on gdk_screen_set_composited(). With blessings, thank you!
Created attachment 339100 [details] [review] GDK/Win32/4.0: Enable HiDPI Hi, There needs to be more updates to this patch so that it will work with the current code base in 3.89/4.x. I will try to keep the patches as current as possible. With blessings, thank you!
Review of attachment 339100 [details] [review]: See the comments ::: gdk/win32/gdkdisplay-win32.c @@ 828,3 @@ { if (display_win32->shcore_funcs.hshcore != NULL) FreeLibrary (display_win32->shcore_funcs.hshcore); dispose can run several times. you should set hshcore to NULL otherwise you might endup calling FreeLibrary several times @@ 1027,3 @@ switch (status) { case DPI_STATUS_SUCCESS: the case should be at teh same level as { ::: gdk/win32/gdkgeometry-win32.c @@ 87,1 @@ { worth fixing this indentation as part of the patch ::: gdk/win32/gdkscreen-win32.c @@ 117,3 @@ impl_win32->handle, NULL); no need for this empty line
Created attachment 339103 [details] [review] GDK/Win32/4.0: Enable HiDPI (reprise) Hi Nacho, Thanks for the comments, here comes the new patch with the formatting issues resolved. With blessings, thank you!
Review of attachment 339103 [details] [review]: Let's get this in if it is ready.
Review of attachment 339103 [details] [review]: Hi Nacho, Thanks! Here we have HiDPI support for Windows for GTK -4.x, pushed as 6abd65c. For now when scale=2 or on HiDPI displays, things with GL will run slower (there is no slow down in the 3.x patch, which is not very much different, so could be other factors affecting this--a similar slow down is also exhibited on Linux as well). I made the 3.x patch more conservative, so wonder we want to aim for that as well. With blessings, and cheers!
(In reply to Matthias Clasen from comment #33) > Comment on attachment 330429 [details] [review] [review] > Update GTK Windows icon (now scles up to 256x256) > > Attachment 330429 [details] pushed as 09004b5 - Update GTK Windows icon > (now scles up to 256x256) Is there stuff missing at the end of the opening <svg> tag? It doesn't seem to be closed, and trying to view it causes the browser to bail as follows: > XML Parsing Error: not well-formed > Location: https://git.gnome.org/browse/gtk /plain/gdk/win32/rc/gtk.svg?id=09004b5 > Line Number 19, Column 3: <defs > --^
Created attachment 339123 [details] [review] W32: Fix malformed svg file Yes, there was a '>' missing. Probably due to my post-Inkscape editing or something.
Comment on attachment 339123 [details] [review] W32: Fix malformed svg file Attachment 339123 [details] pushed as e75878f - W32: Fix malformed svg file
Created attachment 339221 [details] [review] GDK/Win32/3.x: Enable HiDPI Hi, This is the new version of the patch for GTK 3.x, to: -Remove extra whitespaces -Deal with the issues Nacho pointed out in comment 52. Again, for the 3.x patch, the DPI awareness mode is set as process DPI aware (as the mode that Windows Vista/7 supports), unlike the 4.x mode where we will ultimately see whether we can do per-monitor DPI awareness, as newer developments are unlikely for GTK -3.x, and we want to be more conservative in 3.x as a result. With blessings, thank you!
Review of attachment 339221 [details] [review]: OK, let's get it in so we have time to get it tested in case there are problems.
Review of attachment 339221 [details] [review]: Hi Nacho, Thanks, this is pushed to gtk-3-22 as 4add92a. I think we should keep this bug open for some time in case of problems. With blessings, thank you, and cheers!
GTK 3.22.3 fails to build with mingw-w64-headers 5.0.0: ../../../gdk/win32/gdkdisplay-win32.c: In function '_gdk_win32_display_get_monitor_scale_factor': ../../../gdk/win32/gdkdisplay-win32.c:1181:20: error: 'USER_DEFAULT_SCREEN_DPI' undeclared (first use in this function) *dpi = USER_DEFAULT_SCREEN_DPI; ^~~~~~~~~~~~~~~~~~~~~~~ ../../../gdk/win32/gdkdisplay-win32.c:1181:20: note: each undeclared identifier is reported only once for each function it appears in ../../../gdk/win32/gdkdisplay-win32.c:1211:1: warning: control reaches end of non-void function [-Wreturn-type] } ^ In winuser.h: #if _WIN32_WINNT >= 0x0600 #define USER_DEFAULT_SCREEN_DPI 96 WINUSERAPI WINBOOL WINAPI SetProcessDPIAware (VOID); WINUSERAPI WINBOOL WINAPI IsProcessDPIAware (VOID); #endif It seems that we needs to define a macro to get the definition.
I usually just build with CPPFLAGS="-D_WIN32_WINNT=0x600", but you're right, this should be defined in GTK source.
Hi, I think since we already require Vista or later we could just define _WIN32_WINNT in gdkdisplay-win32.c, or just define the constant when needed. I will fix that shortly. With blessings, thank you!
Hi, This is now fixed in gtk-3-22 and master (4.x). Thanks for the heads up, with blessings!
It builds without problem now.
Hi LRN, (In reply to LRN from comment #34) > > Also noticed the abovementioned slowdowns (when resizing or doing animated > page switchers on gtk3-widget-factory), but i think this is just cairo being > slow, nothing we can do about it... I think things should now be much better due to the patch in bug 774114, as I tried the build that has that patch included. --- Hi, Since it was some time after any further issues reported, I will close this bug. Please feel free to reopen this bug if new issues should appear. --- With blessings, thank you!