GNOME Bugzilla – Bug 777031
win32 HiDPI assert
Last modified: 2017-01-09 14:10:08 UTC
Got a bug report that this triggers: https://git.gnome.org/browse/gtk+/tree/gdk/win32/gdkdisplay-win32.c?h=3.22.5#n941 https://github.com/quodlibet/quodlibet/issues/2186 From what I see this assert is reached in case SetProcessDPIAwareness returns E_ACCESSDENIED or shcore.dll is not found. I think the logic should be changed to be the same as the windows 8 case below it.
Created attachment 343136 [details] [review] GDK W32: Remove unneeded assertion v1 Just set check_for_dpi_awareness = TRUE and eventually it will be handled correctly, even if setDpiAwareFunc() returns E_ACCESSDENIED or shcore functions are NULL.
thanks, lgtm at least
Hi LRN, Hmm, I forgot to check for check_for_dpi_awareness before the assert... oops. I would actually rather check if check_for_dpi_awareness is FALSE before going into the block where the assert is done, because something is wrong if we get into that block otherwise. Let me know it this issue persists, because this should be caused by access denied, not the shcore items being NULL. With blessings, thank you!
My understanding is that first part of the code tries to *set* DPI awareness. If that can't be done (because functions are missing, or they return certain errors), the second part is used to check DPI awareness that is actually set (by the system, or manifest, or some other sort of uncontrollable means). Therefore i think that display->shcore_funcs.setDpiAwareFunc == NULL should lead to check_for_dpi_awareness = TRUE, and getting E_ACCESSDENIED should do the same. Setting status and DPI awareness at this point is premature.
Hi LRN, This seems that the program is on 8.1+, hence this path is taken. Notice for Vista~8 something similar is done for HiDPI support. We can certainly check for DPI awareness setting if acquiring the function failed, and end up without HiDPI support in the end, as checking for the DPI setting can very well fail, since we are still using shcore.dll. To me this would be more like a system issue if shcore.dll can't be loaded with the needed functions, as shcore.dll is part of 8.1+. My take on this. With blessings, and cheers!
I'm not sure whether you're agreeing or disagreeing with my assessment, so i'll just push this patch as-is, and we'll adjust the code later if need be.
Attachment 343136 [details] pushed into gtk-3-22 as commit 51645b585123de193da0360d3a69f767a3c4fa59