Changes multihead reorganizing code for win32 support, mostly from a patch
Wed Jun 5 18:34:47 2002 Owen Taylor <otaylor@redhat.com>
Changes multihead reorganizing code for win32 support,
mostly from a patch by Hans Breuer.
* gdk/gdkcolor.c gdk/x11/gdkcolor-x11.c gdk/gdkcursor.c
gdk/x11/gdkcursor-x11.c gdk/gdkevents.c gdk/x11/gdkevents-x11.c
gdk/gdkfont.c gdk/x11/gdkfont-x11.c gdk/gdkkeys.c
gdk/x11/gdkkeys-x11.c gdk/gdkimage.c gdk/x11/gdkimage-x11.c
gdk/gdkscreen.c gdk/x11/gdkmain-x11.c
gdk/gdkdisplay.c gdk/gdkevents-x11.c gdk/gdkpango.c
gdk/x11/gdkpango-x11.c gdk/gdkselection.c
gdk/x11/gdkselection-x11.c gdk/gdkwindow.c
gdk/x11/gdkwindow-x11.c gdk/gdkvisual.c gdk/x11/gdkvisual-x11.c:
Move port-independent singlehead wrapper functions into
port-independent part of GDK. (#80009)
* gdk/win32/gdkcolor-win32.c gdk/win32/gdkcursor-win32.c
gdk/win32/gdkevents-win32.c gdk/win32/gdkfont-win32.c
gdk/win32/gdkimage-win32.c gdk/win32/gdkkeys-win32.c
gdk/win32/gdkmain-win32.c gdk/win32/gdkproperty-win32.c
gdk/win32/gdkselection-win32.c gdk/win32/gkwindow-win32.c:
Turn singlehead functions into "multihead" functions that ignore
their GdkDisplay or GdkScreen arguments.
* gdk/win32/gdkdrawable-win32.c gdk/win32/gdkevents-win32.c
gdk/win32/gdkinput-win32.c gdk/win32/gdkprivate-win32.h:
Misc multihead-compatibility changes.
* gtk/gtk.def gdk/gdk.def: Update for multihead functions.
* gdk/gdkcolormap.h gdk/gdkvisual.h gdk/x11/gdkcolormap-x11.c
gdk/x11/gdkvisual-x11.c: Remove the screen fields
from the public parts of the colormap/visual structures, add accessors
instead.
* gdk/gdkpixbuf-render.c gdk/gdkpixmap.c gdk/gdkrgb.c
gdk/x11/gdkcolormap-x11.c gdk/x11/gdkimage-x11.c
gdk/x11/gdkimage-x11.c gdk/x11/gdkprivate-x11.h gtk/gtkgc.c
gtk/gtkstyle.c gtk/gtkwidget.c: Use accessors to get the screen
for colormaps, visuals; move the fields into the private
structures for the x11 backend.
* gdk/gdkdisplay.[ch] gdk/x11/gdkdisplay-x11.[ch]
gdk/gdkscreen.[ch] gdk/x11/gdkscreen-x11.c:
Remove virtualization of screen and display functions.
(#79990, patch from Erwann Chenede)
* gdk/win32/gdkdisplay-x11.c gdk/win32/gdkscreen-win32.c
gdk/win32/{Makefile.am, makefile.msc, makefile.mingw}:
New files containing stub implementations of Display,
Screen functions.
* gdk/x11/gdkscreen-x11.[ch] gdk/x11/gdkdisplay-x11.[ch]
gdk/x11/gdkx.h: Clean up function exports and what
headers they are in. (#79954)
* gdk/x11/gdkx.h: Fix macro that was referring to a non-existant
screen->screen_num. (In the patch for #79972, Erwann Chenede)
* gdk/gdkscreen.c gdk/gdkwindow.c gdk/x11/gdkinternals.h
gdk/x11/gdkscreen-x11.c: Fix gdk_screen_get_window_at_pointer()
to use window hooks. (#79972, patch partly from Erwann Chenede)
* gdk/x11/gdkdisplay-x11.c gdk/x11/gdkevents-x11.c: Fix
some warnings.
2002-06-06 00:26:42 +00:00
|
|
|
/* GDK - The GIMP Drawing Kit
|
2005-04-03 21:03:08 +00:00
|
|
|
* Copyright (C) 2002,2005 Hans Breuer
|
gdk/win32/gdkinput-win32.h Drop the GdkEvent* parameter, it wasn't used.
2003-08-07 Tor Lillqvist <tml@iki.fi>
* gdk/win32/gdkinput-win32.h
* gdk/win32/gdkinput-win32.c (_gdk_input_configure_event,
_gdk_input_enter_event): Drop the GdkEvent* parameter, it wasn't
used.
* gdk/win32/gdkevents-win32.c (gdk_event_translate): Adapt caller
accordingly, in fact an uninitialised variable was dereferenced.
[Win32] Add support for multiple monitors.
* gdk/win32/gdkprivate-win32.h
* gdk/win32/gdkglobals-win32.c: New global variables for
multiple-monitor info: _gdk_num_monitors, _gdk_monitors, and
_gdk_offset_x and _gdk_offset_y.
* gdk/win32/gdkdisplay-win32.c (count_monitor, enum_monitor): New
functions, enumeration functions passed to EnumDisplayMonitors().
(gdk_display_open): If the EnumDisplayMonitors() and
GetMonitorInfo() API is present (on Win98, Win2000 and newer), use
if to find out monitor info.
Calculate the offset between Win32 coordinates (relative to the
primary monitor's origin (and thus negative on monitors to the
left of or above it), and GDK's (visible coordinates should be
non-negative).
* gdk/win32/gdkscreen-win32 (gdk_screen_get_n_monitors,
gdk_screen_get_monitor_geometry): Use information collected above.
(gdk_window_move, gdk_window_move_resize_window_get_geometry):
Subtract _gdk_offset_{x,y} from GDK root window coordinates.
(gdk_window_get_geometry, gdk_window_get_origin,
gdk_window_get_frame_extents): For top-level windows, add
_gdk_offset_{x,y} to GDK root window coordinates
Still need to handle multiple monitors in
gdk_window_fullscreen(). Probably should make the window
fullscreen on the monitor where the cursor is?
* gdk/win32/gdkevents-win32.c: Add _gdk_offset_{x,y} to all GDK
root window coordinates in GdkEvents.
[Win32] Fix geometry hint handling. Add support for resize
increment and base size, and aspect ratio geometry hints. The
"gridded geometry" test in testgtk now works beautifully.
* gdk/win32/gdkwindow-win32.c (gdk_window_set_geometry_hints):
Turns out this function shouldn't actually ever modify the
window's size, just store the hints. (Old code kept for a while
inside #if 0.)
(gdk_window_set_hints): Remove presumably broken code that handles
the position hints, this function is obsolete anyway.
* gdk/win32/gdkevents-win32.c: Drop the current_{x,y}_root
variables, not used.
(adjust_drag): New function, used to implement resize increment
hints.
(gdk_event_translate): Handle WM_SIZING, implement resize
increment and base size, and aspect ratio geometry hints here. The
WM_GETMINMAXINFO handler takes care of the minimum and maximum
size hints as before. Fix the WM_GETMINMAXINFO handler to take
into account window decorations. No need to modify the
ptMaxPosition and ptMaxSize fields in the MINMAXINFO struct,
the defaults are fine.
* gdk/win32/gdkprivate-win32.h
* gdk/win32/gdkwindow-win32.c (_gdk_win32_adjust_client_rect,
_gdk_win32_get_adjusted_client_rect): New helper functions.
2003-08-07 22:17:18 +00:00
|
|
|
* Copyright (C) 2003 Tor Lillqvist
|
Changes multihead reorganizing code for win32 support, mostly from a patch
Wed Jun 5 18:34:47 2002 Owen Taylor <otaylor@redhat.com>
Changes multihead reorganizing code for win32 support,
mostly from a patch by Hans Breuer.
* gdk/gdkcolor.c gdk/x11/gdkcolor-x11.c gdk/gdkcursor.c
gdk/x11/gdkcursor-x11.c gdk/gdkevents.c gdk/x11/gdkevents-x11.c
gdk/gdkfont.c gdk/x11/gdkfont-x11.c gdk/gdkkeys.c
gdk/x11/gdkkeys-x11.c gdk/gdkimage.c gdk/x11/gdkimage-x11.c
gdk/gdkscreen.c gdk/x11/gdkmain-x11.c
gdk/gdkdisplay.c gdk/gdkevents-x11.c gdk/gdkpango.c
gdk/x11/gdkpango-x11.c gdk/gdkselection.c
gdk/x11/gdkselection-x11.c gdk/gdkwindow.c
gdk/x11/gdkwindow-x11.c gdk/gdkvisual.c gdk/x11/gdkvisual-x11.c:
Move port-independent singlehead wrapper functions into
port-independent part of GDK. (#80009)
* gdk/win32/gdkcolor-win32.c gdk/win32/gdkcursor-win32.c
gdk/win32/gdkevents-win32.c gdk/win32/gdkfont-win32.c
gdk/win32/gdkimage-win32.c gdk/win32/gdkkeys-win32.c
gdk/win32/gdkmain-win32.c gdk/win32/gdkproperty-win32.c
gdk/win32/gdkselection-win32.c gdk/win32/gkwindow-win32.c:
Turn singlehead functions into "multihead" functions that ignore
their GdkDisplay or GdkScreen arguments.
* gdk/win32/gdkdrawable-win32.c gdk/win32/gdkevents-win32.c
gdk/win32/gdkinput-win32.c gdk/win32/gdkprivate-win32.h:
Misc multihead-compatibility changes.
* gtk/gtk.def gdk/gdk.def: Update for multihead functions.
* gdk/gdkcolormap.h gdk/gdkvisual.h gdk/x11/gdkcolormap-x11.c
gdk/x11/gdkvisual-x11.c: Remove the screen fields
from the public parts of the colormap/visual structures, add accessors
instead.
* gdk/gdkpixbuf-render.c gdk/gdkpixmap.c gdk/gdkrgb.c
gdk/x11/gdkcolormap-x11.c gdk/x11/gdkimage-x11.c
gdk/x11/gdkimage-x11.c gdk/x11/gdkprivate-x11.h gtk/gtkgc.c
gtk/gtkstyle.c gtk/gtkwidget.c: Use accessors to get the screen
for colormaps, visuals; move the fields into the private
structures for the x11 backend.
* gdk/gdkdisplay.[ch] gdk/x11/gdkdisplay-x11.[ch]
gdk/gdkscreen.[ch] gdk/x11/gdkscreen-x11.c:
Remove virtualization of screen and display functions.
(#79990, patch from Erwann Chenede)
* gdk/win32/gdkdisplay-x11.c gdk/win32/gdkscreen-win32.c
gdk/win32/{Makefile.am, makefile.msc, makefile.mingw}:
New files containing stub implementations of Display,
Screen functions.
* gdk/x11/gdkscreen-x11.[ch] gdk/x11/gdkdisplay-x11.[ch]
gdk/x11/gdkx.h: Clean up function exports and what
headers they are in. (#79954)
* gdk/x11/gdkx.h: Fix macro that was referring to a non-existant
screen->screen_num. (In the patch for #79972, Erwann Chenede)
* gdk/gdkscreen.c gdk/gdkwindow.c gdk/x11/gdkinternals.h
gdk/x11/gdkscreen-x11.c: Fix gdk_screen_get_window_at_pointer()
to use window hooks. (#79972, patch partly from Erwann Chenede)
* gdk/x11/gdkdisplay-x11.c gdk/x11/gdkevents-x11.c: Fix
some warnings.
2002-06-06 00:26:42 +00:00
|
|
|
*
|
|
|
|
* This library is free software; you can redistribute it and/or
|
|
|
|
* modify it under the terms of the GNU Lesser General Public
|
|
|
|
* License as published by the Free Software Foundation; either
|
|
|
|
* version 2 of the License, or (at your option) any later version.
|
|
|
|
*
|
|
|
|
* This library is distributed in the hope that it will be useful,
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
|
|
|
|
* Lesser General Public License for more details.
|
|
|
|
*
|
|
|
|
* You should have received a copy of the GNU Lesser General Public
|
2012-02-27 13:01:10 +00:00
|
|
|
* License along with this library. If not, see <http://www.gnu.org/licenses/>.
|
Changes multihead reorganizing code for win32 support, mostly from a patch
Wed Jun 5 18:34:47 2002 Owen Taylor <otaylor@redhat.com>
Changes multihead reorganizing code for win32 support,
mostly from a patch by Hans Breuer.
* gdk/gdkcolor.c gdk/x11/gdkcolor-x11.c gdk/gdkcursor.c
gdk/x11/gdkcursor-x11.c gdk/gdkevents.c gdk/x11/gdkevents-x11.c
gdk/gdkfont.c gdk/x11/gdkfont-x11.c gdk/gdkkeys.c
gdk/x11/gdkkeys-x11.c gdk/gdkimage.c gdk/x11/gdkimage-x11.c
gdk/gdkscreen.c gdk/x11/gdkmain-x11.c
gdk/gdkdisplay.c gdk/gdkevents-x11.c gdk/gdkpango.c
gdk/x11/gdkpango-x11.c gdk/gdkselection.c
gdk/x11/gdkselection-x11.c gdk/gdkwindow.c
gdk/x11/gdkwindow-x11.c gdk/gdkvisual.c gdk/x11/gdkvisual-x11.c:
Move port-independent singlehead wrapper functions into
port-independent part of GDK. (#80009)
* gdk/win32/gdkcolor-win32.c gdk/win32/gdkcursor-win32.c
gdk/win32/gdkevents-win32.c gdk/win32/gdkfont-win32.c
gdk/win32/gdkimage-win32.c gdk/win32/gdkkeys-win32.c
gdk/win32/gdkmain-win32.c gdk/win32/gdkproperty-win32.c
gdk/win32/gdkselection-win32.c gdk/win32/gkwindow-win32.c:
Turn singlehead functions into "multihead" functions that ignore
their GdkDisplay or GdkScreen arguments.
* gdk/win32/gdkdrawable-win32.c gdk/win32/gdkevents-win32.c
gdk/win32/gdkinput-win32.c gdk/win32/gdkprivate-win32.h:
Misc multihead-compatibility changes.
* gtk/gtk.def gdk/gdk.def: Update for multihead functions.
* gdk/gdkcolormap.h gdk/gdkvisual.h gdk/x11/gdkcolormap-x11.c
gdk/x11/gdkvisual-x11.c: Remove the screen fields
from the public parts of the colormap/visual structures, add accessors
instead.
* gdk/gdkpixbuf-render.c gdk/gdkpixmap.c gdk/gdkrgb.c
gdk/x11/gdkcolormap-x11.c gdk/x11/gdkimage-x11.c
gdk/x11/gdkimage-x11.c gdk/x11/gdkprivate-x11.h gtk/gtkgc.c
gtk/gtkstyle.c gtk/gtkwidget.c: Use accessors to get the screen
for colormaps, visuals; move the fields into the private
structures for the x11 backend.
* gdk/gdkdisplay.[ch] gdk/x11/gdkdisplay-x11.[ch]
gdk/gdkscreen.[ch] gdk/x11/gdkscreen-x11.c:
Remove virtualization of screen and display functions.
(#79990, patch from Erwann Chenede)
* gdk/win32/gdkdisplay-x11.c gdk/win32/gdkscreen-win32.c
gdk/win32/{Makefile.am, makefile.msc, makefile.mingw}:
New files containing stub implementations of Display,
Screen functions.
* gdk/x11/gdkscreen-x11.[ch] gdk/x11/gdkdisplay-x11.[ch]
gdk/x11/gdkx.h: Clean up function exports and what
headers they are in. (#79954)
* gdk/x11/gdkx.h: Fix macro that was referring to a non-existant
screen->screen_num. (In the patch for #79972, Erwann Chenede)
* gdk/gdkscreen.c gdk/gdkwindow.c gdk/x11/gdkinternals.h
gdk/x11/gdkscreen-x11.c: Fix gdk_screen_get_window_at_pointer()
to use window hooks. (#79972, patch partly from Erwann Chenede)
* gdk/x11/gdkdisplay-x11.c gdk/x11/gdkevents-x11.c: Fix
some warnings.
2002-06-06 00:26:42 +00:00
|
|
|
*/
|
|
|
|
|
2008-06-22 14:28:52 +00:00
|
|
|
#include "config.h"
|
2016-11-11 12:53:41 +00:00
|
|
|
|
2016-12-28 14:25:07 +00:00
|
|
|
#define VK_USE_PLATFORM_WIN32_KHR
|
2016-11-11 12:53:41 +00:00
|
|
|
|
2002-11-16 21:51:47 +00:00
|
|
|
#include "gdk.h"
|
Changes multihead reorganizing code for win32 support, mostly from a patch
Wed Jun 5 18:34:47 2002 Owen Taylor <otaylor@redhat.com>
Changes multihead reorganizing code for win32 support,
mostly from a patch by Hans Breuer.
* gdk/gdkcolor.c gdk/x11/gdkcolor-x11.c gdk/gdkcursor.c
gdk/x11/gdkcursor-x11.c gdk/gdkevents.c gdk/x11/gdkevents-x11.c
gdk/gdkfont.c gdk/x11/gdkfont-x11.c gdk/gdkkeys.c
gdk/x11/gdkkeys-x11.c gdk/gdkimage.c gdk/x11/gdkimage-x11.c
gdk/gdkscreen.c gdk/x11/gdkmain-x11.c
gdk/gdkdisplay.c gdk/gdkevents-x11.c gdk/gdkpango.c
gdk/x11/gdkpango-x11.c gdk/gdkselection.c
gdk/x11/gdkselection-x11.c gdk/gdkwindow.c
gdk/x11/gdkwindow-x11.c gdk/gdkvisual.c gdk/x11/gdkvisual-x11.c:
Move port-independent singlehead wrapper functions into
port-independent part of GDK. (#80009)
* gdk/win32/gdkcolor-win32.c gdk/win32/gdkcursor-win32.c
gdk/win32/gdkevents-win32.c gdk/win32/gdkfont-win32.c
gdk/win32/gdkimage-win32.c gdk/win32/gdkkeys-win32.c
gdk/win32/gdkmain-win32.c gdk/win32/gdkproperty-win32.c
gdk/win32/gdkselection-win32.c gdk/win32/gkwindow-win32.c:
Turn singlehead functions into "multihead" functions that ignore
their GdkDisplay or GdkScreen arguments.
* gdk/win32/gdkdrawable-win32.c gdk/win32/gdkevents-win32.c
gdk/win32/gdkinput-win32.c gdk/win32/gdkprivate-win32.h:
Misc multihead-compatibility changes.
* gtk/gtk.def gdk/gdk.def: Update for multihead functions.
* gdk/gdkcolormap.h gdk/gdkvisual.h gdk/x11/gdkcolormap-x11.c
gdk/x11/gdkvisual-x11.c: Remove the screen fields
from the public parts of the colormap/visual structures, add accessors
instead.
* gdk/gdkpixbuf-render.c gdk/gdkpixmap.c gdk/gdkrgb.c
gdk/x11/gdkcolormap-x11.c gdk/x11/gdkimage-x11.c
gdk/x11/gdkimage-x11.c gdk/x11/gdkprivate-x11.h gtk/gtkgc.c
gtk/gtkstyle.c gtk/gtkwidget.c: Use accessors to get the screen
for colormaps, visuals; move the fields into the private
structures for the x11 backend.
* gdk/gdkdisplay.[ch] gdk/x11/gdkdisplay-x11.[ch]
gdk/gdkscreen.[ch] gdk/x11/gdkscreen-x11.c:
Remove virtualization of screen and display functions.
(#79990, patch from Erwann Chenede)
* gdk/win32/gdkdisplay-x11.c gdk/win32/gdkscreen-win32.c
gdk/win32/{Makefile.am, makefile.msc, makefile.mingw}:
New files containing stub implementations of Display,
Screen functions.
* gdk/x11/gdkscreen-x11.[ch] gdk/x11/gdkdisplay-x11.[ch]
gdk/x11/gdkx.h: Clean up function exports and what
headers they are in. (#79954)
* gdk/x11/gdkx.h: Fix macro that was referring to a non-existant
screen->screen_num. (In the patch for #79972, Erwann Chenede)
* gdk/gdkscreen.c gdk/gdkwindow.c gdk/x11/gdkinternals.h
gdk/x11/gdkscreen-x11.c: Fix gdk_screen_get_window_at_pointer()
to use window hooks. (#79972, patch partly from Erwann Chenede)
* gdk/x11/gdkdisplay-x11.c gdk/x11/gdkevents-x11.c: Fix
some warnings.
2002-06-06 00:26:42 +00:00
|
|
|
#include "gdkprivate-win32.h"
|
2018-04-12 14:48:31 +00:00
|
|
|
#include "gdkcairocontext-win32.h"
|
2018-03-24 16:27:11 +00:00
|
|
|
#include "gdkclipboardprivate.h"
|
|
|
|
#include "gdkclipboard-win32.h"
|
2014-12-17 04:32:04 +00:00
|
|
|
#include "gdkdisplay-win32.h"
|
2016-02-22 20:01:24 +00:00
|
|
|
#include "gdkdevicemanager-win32.h"
|
2014-12-17 04:32:04 +00:00
|
|
|
#include "gdkglcontext-win32.h"
|
2023-04-21 03:41:48 +00:00
|
|
|
#include "gdksurface-win32.h"
|
2011-01-02 10:51:25 +00:00
|
|
|
#include "gdkwin32display.h"
|
|
|
|
#include "gdkwin32screen.h"
|
2018-03-20 10:46:11 +00:00
|
|
|
#include "gdkwin32surface.h"
|
2016-04-20 07:36:00 +00:00
|
|
|
#include "gdkmonitor-win32.h"
|
2011-11-02 15:49:55 +00:00
|
|
|
#include "gdkwin32.h"
|
2016-12-28 14:25:07 +00:00
|
|
|
#include "gdkvulkancontext-win32.h"
|
Changes multihead reorganizing code for win32 support, mostly from a patch
Wed Jun 5 18:34:47 2002 Owen Taylor <otaylor@redhat.com>
Changes multihead reorganizing code for win32 support,
mostly from a patch by Hans Breuer.
* gdk/gdkcolor.c gdk/x11/gdkcolor-x11.c gdk/gdkcursor.c
gdk/x11/gdkcursor-x11.c gdk/gdkevents.c gdk/x11/gdkevents-x11.c
gdk/gdkfont.c gdk/x11/gdkfont-x11.c gdk/gdkkeys.c
gdk/x11/gdkkeys-x11.c gdk/gdkimage.c gdk/x11/gdkimage-x11.c
gdk/gdkscreen.c gdk/x11/gdkmain-x11.c
gdk/gdkdisplay.c gdk/gdkevents-x11.c gdk/gdkpango.c
gdk/x11/gdkpango-x11.c gdk/gdkselection.c
gdk/x11/gdkselection-x11.c gdk/gdkwindow.c
gdk/x11/gdkwindow-x11.c gdk/gdkvisual.c gdk/x11/gdkvisual-x11.c:
Move port-independent singlehead wrapper functions into
port-independent part of GDK. (#80009)
* gdk/win32/gdkcolor-win32.c gdk/win32/gdkcursor-win32.c
gdk/win32/gdkevents-win32.c gdk/win32/gdkfont-win32.c
gdk/win32/gdkimage-win32.c gdk/win32/gdkkeys-win32.c
gdk/win32/gdkmain-win32.c gdk/win32/gdkproperty-win32.c
gdk/win32/gdkselection-win32.c gdk/win32/gkwindow-win32.c:
Turn singlehead functions into "multihead" functions that ignore
their GdkDisplay or GdkScreen arguments.
* gdk/win32/gdkdrawable-win32.c gdk/win32/gdkevents-win32.c
gdk/win32/gdkinput-win32.c gdk/win32/gdkprivate-win32.h:
Misc multihead-compatibility changes.
* gtk/gtk.def gdk/gdk.def: Update for multihead functions.
* gdk/gdkcolormap.h gdk/gdkvisual.h gdk/x11/gdkcolormap-x11.c
gdk/x11/gdkvisual-x11.c: Remove the screen fields
from the public parts of the colormap/visual structures, add accessors
instead.
* gdk/gdkpixbuf-render.c gdk/gdkpixmap.c gdk/gdkrgb.c
gdk/x11/gdkcolormap-x11.c gdk/x11/gdkimage-x11.c
gdk/x11/gdkimage-x11.c gdk/x11/gdkprivate-x11.h gtk/gtkgc.c
gtk/gtkstyle.c gtk/gtkwidget.c: Use accessors to get the screen
for colormaps, visuals; move the fields into the private
structures for the x11 backend.
* gdk/gdkdisplay.[ch] gdk/x11/gdkdisplay-x11.[ch]
gdk/gdkscreen.[ch] gdk/x11/gdkscreen-x11.c:
Remove virtualization of screen and display functions.
(#79990, patch from Erwann Chenede)
* gdk/win32/gdkdisplay-x11.c gdk/win32/gdkscreen-win32.c
gdk/win32/{Makefile.am, makefile.msc, makefile.mingw}:
New files containing stub implementations of Display,
Screen functions.
* gdk/x11/gdkscreen-x11.[ch] gdk/x11/gdkdisplay-x11.[ch]
gdk/x11/gdkx.h: Clean up function exports and what
headers they are in. (#79954)
* gdk/x11/gdkx.h: Fix macro that was referring to a non-existant
screen->screen_num. (In the patch for #79972, Erwann Chenede)
* gdk/gdkscreen.c gdk/gdkwindow.c gdk/x11/gdkinternals.h
gdk/x11/gdkscreen-x11.c: Fix gdk_screen_get_window_at_pointer()
to use window hooks. (#79972, patch partly from Erwann Chenede)
* gdk/x11/gdkdisplay-x11.c gdk/x11/gdkevents-x11.c: Fix
some warnings.
2002-06-06 00:26:42 +00:00
|
|
|
|
2016-11-01 08:42:31 +00:00
|
|
|
#include <dwmapi.h>
|
|
|
|
|
GDK W32: Test for IME correctly
ImmIsIME() doesn't work (always returns TRUE) since Vista.
Use ITfActiveLanguageProfileNotifySink to detect TSF changes,
which are equal to IME changes for us.
Also make sure that IMMultiContext re-loads the IM when keyboard layout
changes, otherwise there's a subtle bug that could happen:
* Run GTK application with non-IME layout (US, for example)
* Focus on an editable widget (GtkEntry, for example)
* IM Context is initialized to use the simple IM
* Switch to an IME layout (such as Korean)
* Start typing
* Since IME module is not loaded yet, keypresses are handled
by a default MS IME handler
* Once IME commits a character, GDK will get a WM_KEYDOWN,
which will trigger a GdkKeyEvent, which will be handled by
an event filter in IM Context, which will finally re-evaluate
its status and load IME, and only after that GTK will get
to handle IME by itself - but by that point input would
already be broken.
To avoid this we can emit a dummy event (with Void keyval),
which will cause IM Context to load the appropriate module
immediately.
2019-03-22 15:10:02 +00:00
|
|
|
#include "gdkwin32langnotification.h"
|
2021-10-07 07:26:49 +00:00
|
|
|
#ifdef HAVE_EGL
|
2018-07-31 10:11:26 +00:00
|
|
|
# include <epoxy/egl.h>
|
|
|
|
#endif
|
GDK W32: Test for IME correctly
ImmIsIME() doesn't work (always returns TRUE) since Vista.
Use ITfActiveLanguageProfileNotifySink to detect TSF changes,
which are equal to IME changes for us.
Also make sure that IMMultiContext re-loads the IM when keyboard layout
changes, otherwise there's a subtle bug that could happen:
* Run GTK application with non-IME layout (US, for example)
* Focus on an editable widget (GtkEntry, for example)
* IM Context is initialized to use the simple IM
* Switch to an IME layout (such as Korean)
* Start typing
* Since IME module is not loaded yet, keypresses are handled
by a default MS IME handler
* Once IME commits a character, GDK will get a WM_KEYDOWN,
which will trigger a GdkKeyEvent, which will be handled by
an event filter in IM Context, which will finally re-evaluate
its status and load IME, and only after that GTK will get
to handle IME by itself - but by that point input would
already be broken.
To avoid this we can emit a dummy event (with Void keyval),
which will cause IM Context to load the appropriate module
immediately.
2019-03-22 15:10:02 +00:00
|
|
|
|
2019-05-07 07:09:03 +00:00
|
|
|
#ifndef IMAGE_FILE_MACHINE_ARM64
|
|
|
|
# define IMAGE_FILE_MACHINE_ARM64 0xAA64
|
|
|
|
#endif
|
|
|
|
|
2015-10-29 16:20:54 +00:00
|
|
|
static int debug_indent = 0;
|
|
|
|
|
2018-03-24 16:39:13 +00:00
|
|
|
/**
|
|
|
|
* gdk_win32_display_add_filter:
|
2021-05-20 03:39:18 +00:00
|
|
|
* @display: a `GdkWin32Display`
|
2022-08-23 08:57:20 +00:00
|
|
|
* @function: (scope notified): filter callback
|
|
|
|
* @data: (closure): data to pass to filter callback
|
2018-03-24 16:39:13 +00:00
|
|
|
*
|
|
|
|
* Adds an event filter to @window, allowing you to intercept messages
|
|
|
|
* before they reach GDK. This is a low-level operation and makes it
|
2020-09-12 16:01:04 +00:00
|
|
|
* easy to break GDK and/or GTK, so you have to know what you're
|
2018-03-24 16:39:13 +00:00
|
|
|
* doing.
|
|
|
|
**/
|
|
|
|
void
|
|
|
|
gdk_win32_display_add_filter (GdkWin32Display *display,
|
|
|
|
GdkWin32MessageFilterFunc function,
|
|
|
|
gpointer data)
|
|
|
|
{
|
|
|
|
GList *tmp_list;
|
|
|
|
GdkWin32MessageFilter *filter;
|
|
|
|
|
|
|
|
g_return_if_fail (GDK_IS_WIN32_DISPLAY (display));
|
|
|
|
|
|
|
|
tmp_list = display->filters;
|
|
|
|
|
|
|
|
for (tmp_list = display->filters; tmp_list; tmp_list = tmp_list->next)
|
|
|
|
{
|
|
|
|
filter = (GdkWin32MessageFilter *) tmp_list->data;
|
|
|
|
|
|
|
|
if ((filter->function == function) && (filter->data == data))
|
|
|
|
{
|
|
|
|
filter->ref_count++;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
filter = g_new (GdkWin32MessageFilter, 1);
|
|
|
|
filter->function = function;
|
|
|
|
filter->data = data;
|
|
|
|
filter->ref_count = 1;
|
|
|
|
filter->removed = FALSE;
|
|
|
|
|
|
|
|
display->filters = g_list_append (display->filters, filter);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* _gdk_win32_message_filter_unref:
|
2021-05-20 03:39:18 +00:00
|
|
|
* @display: A `GdkWin32Display`
|
2018-03-24 16:39:13 +00:00
|
|
|
* @filter: A message filter
|
|
|
|
*
|
|
|
|
* Release a reference to @filter. Note this function may
|
|
|
|
* mutate the list storage, so you need to handle this
|
|
|
|
* if iterating over a list of filters.
|
|
|
|
*/
|
|
|
|
void
|
|
|
|
_gdk_win32_message_filter_unref (GdkWin32Display *display,
|
|
|
|
GdkWin32MessageFilter *filter)
|
|
|
|
{
|
|
|
|
GList **filters;
|
|
|
|
GList *tmp_list;
|
|
|
|
|
|
|
|
filters = &display->filters;
|
|
|
|
|
|
|
|
tmp_list = *filters;
|
|
|
|
while (tmp_list)
|
|
|
|
{
|
|
|
|
GdkWin32MessageFilter *iter_filter = tmp_list->data;
|
|
|
|
GList *node;
|
|
|
|
|
|
|
|
node = tmp_list;
|
|
|
|
tmp_list = tmp_list->next;
|
|
|
|
|
|
|
|
if (iter_filter != filter)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
g_assert (iter_filter->ref_count > 0);
|
|
|
|
|
|
|
|
filter->ref_count--;
|
|
|
|
if (filter->ref_count != 0)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
*filters = g_list_remove_link (*filters, node);
|
|
|
|
g_free (filter);
|
|
|
|
g_list_free_1 (node);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* gdk_win32_display_remove_filter:
|
2021-05-20 03:39:18 +00:00
|
|
|
* @display: A `GdkWin32Display`
|
2022-08-23 08:57:20 +00:00
|
|
|
* @function: (scope notified): previously-added filter function
|
|
|
|
* @data: (closure): user data for previously-added filter function
|
2018-03-24 16:39:13 +00:00
|
|
|
*
|
|
|
|
* Remove a filter previously added with gdk_win32_display_add_filter().
|
|
|
|
*/
|
|
|
|
void
|
|
|
|
gdk_win32_display_remove_filter (GdkWin32Display *display,
|
|
|
|
GdkWin32MessageFilterFunc function,
|
|
|
|
gpointer data)
|
|
|
|
{
|
|
|
|
GList *tmp_list;
|
|
|
|
GdkWin32MessageFilter *filter;
|
|
|
|
|
|
|
|
g_return_if_fail (GDK_IS_WIN32_DISPLAY (display));
|
|
|
|
|
|
|
|
tmp_list = display->filters;
|
|
|
|
|
|
|
|
while (tmp_list)
|
|
|
|
{
|
|
|
|
filter = (GdkWin32MessageFilter *) tmp_list->data;
|
|
|
|
tmp_list = tmp_list->next;
|
|
|
|
|
|
|
|
if ((filter->function == function) && (filter->data == data))
|
|
|
|
{
|
|
|
|
filter->removed = TRUE;
|
|
|
|
|
|
|
|
_gdk_win32_message_filter_unref (display, filter);
|
|
|
|
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-04-20 07:36:00 +00:00
|
|
|
static GdkMonitor *
|
|
|
|
_gdk_win32_display_find_matching_monitor (GdkWin32Display *win32_display,
|
|
|
|
GdkMonitor *needle)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
2020-05-13 02:44:06 +00:00
|
|
|
for (i = 0; i < g_list_model_get_n_items (win32_display->monitors); i++)
|
2016-04-20 07:36:00 +00:00
|
|
|
{
|
|
|
|
GdkWin32Monitor *m;
|
|
|
|
|
2020-05-13 02:44:06 +00:00
|
|
|
m = g_list_model_get_item (win32_display->monitors, i);
|
|
|
|
g_object_unref (m);
|
2016-04-20 07:36:00 +00:00
|
|
|
|
|
|
|
if (_gdk_win32_monitor_compare (m, GDK_WIN32_MONITOR (needle)) == 0)
|
|
|
|
return GDK_MONITOR (m);
|
|
|
|
}
|
|
|
|
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2020-05-13 02:44:06 +00:00
|
|
|
void
|
2016-04-20 07:36:00 +00:00
|
|
|
_gdk_win32_display_init_monitors (GdkWin32Display *win32_display)
|
|
|
|
{
|
|
|
|
GPtrArray *new_monitors;
|
2020-07-24 13:54:49 +00:00
|
|
|
int i;
|
2016-04-20 07:36:00 +00:00
|
|
|
GdkWin32Monitor *primary_to_move = NULL;
|
|
|
|
|
2020-05-13 02:44:06 +00:00
|
|
|
for (i = 0; i < g_list_model_get_n_items (win32_display->monitors); i++)
|
|
|
|
{
|
|
|
|
GdkWin32Monitor *m;
|
|
|
|
|
|
|
|
m = g_list_model_get_item (win32_display->monitors, i);
|
|
|
|
m->remove = TRUE;
|
|
|
|
g_object_unref (m);
|
|
|
|
}
|
2016-04-20 07:36:00 +00:00
|
|
|
|
|
|
|
new_monitors = _gdk_win32_display_get_monitor_list (win32_display);
|
|
|
|
|
|
|
|
for (i = 0; i < new_monitors->len; i++)
|
|
|
|
{
|
|
|
|
GdkWin32Monitor *w32_m;
|
|
|
|
GdkMonitor *m;
|
|
|
|
GdkWin32Monitor *w32_ex_monitor;
|
|
|
|
GdkMonitor *ex_monitor;
|
2020-05-17 03:23:16 +00:00
|
|
|
GdkRectangle geometry;
|
2016-04-20 07:36:00 +00:00
|
|
|
GdkRectangle workarea, ex_workarea;
|
|
|
|
|
|
|
|
w32_m = GDK_WIN32_MONITOR (g_ptr_array_index (new_monitors, i));
|
|
|
|
m = GDK_MONITOR (w32_m);
|
|
|
|
ex_monitor = _gdk_win32_display_find_matching_monitor (win32_display, m);
|
|
|
|
w32_ex_monitor = GDK_WIN32_MONITOR (ex_monitor);
|
|
|
|
|
|
|
|
if (ex_monitor == NULL)
|
|
|
|
{
|
|
|
|
w32_m->add = TRUE;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
w32_ex_monitor->remove = FALSE;
|
|
|
|
|
|
|
|
if (i == 0)
|
|
|
|
primary_to_move = w32_ex_monitor;
|
|
|
|
|
|
|
|
gdk_monitor_get_geometry (m, &geometry);
|
2020-07-29 13:47:48 +00:00
|
|
|
gdk_win32_monitor_get_workarea (m, &workarea);
|
|
|
|
gdk_win32_monitor_get_workarea (ex_monitor, &ex_workarea);
|
2016-04-20 07:36:00 +00:00
|
|
|
|
|
|
|
if (memcmp (&workarea, &ex_workarea, sizeof (GdkRectangle)) != 0)
|
|
|
|
{
|
|
|
|
w32_ex_monitor->work_rect = workarea;
|
|
|
|
}
|
|
|
|
|
2020-05-17 03:23:16 +00:00
|
|
|
gdk_monitor_set_geometry (ex_monitor, &geometry);
|
2016-04-20 07:36:00 +00:00
|
|
|
|
|
|
|
if (gdk_monitor_get_width_mm (m) != gdk_monitor_get_width_mm (ex_monitor) ||
|
|
|
|
gdk_monitor_get_height_mm (m) != gdk_monitor_get_height_mm (ex_monitor))
|
|
|
|
{
|
|
|
|
gdk_monitor_set_physical_size (ex_monitor,
|
|
|
|
gdk_monitor_get_width_mm (m),
|
|
|
|
gdk_monitor_get_height_mm (m));
|
|
|
|
}
|
|
|
|
|
|
|
|
if (g_strcmp0 (gdk_monitor_get_model (m), gdk_monitor_get_model (ex_monitor)) != 0)
|
|
|
|
{
|
|
|
|
gdk_monitor_set_model (ex_monitor,
|
|
|
|
gdk_monitor_get_model (m));
|
|
|
|
}
|
|
|
|
|
|
|
|
if (g_strcmp0 (gdk_monitor_get_manufacturer (m), gdk_monitor_get_manufacturer (ex_monitor)) != 0)
|
|
|
|
{
|
|
|
|
gdk_monitor_set_manufacturer (ex_monitor,
|
|
|
|
gdk_monitor_get_manufacturer (m));
|
|
|
|
}
|
|
|
|
|
|
|
|
if (gdk_monitor_get_refresh_rate (m) != gdk_monitor_get_refresh_rate (ex_monitor))
|
|
|
|
{
|
|
|
|
gdk_monitor_set_refresh_rate (ex_monitor, gdk_monitor_get_refresh_rate (m));
|
|
|
|
}
|
|
|
|
|
|
|
|
if (gdk_monitor_get_scale_factor (m) != gdk_monitor_get_scale_factor (ex_monitor))
|
|
|
|
{
|
|
|
|
gdk_monitor_set_scale_factor (ex_monitor, gdk_monitor_get_scale_factor (m));
|
|
|
|
}
|
|
|
|
|
|
|
|
if (gdk_monitor_get_subpixel_layout (m) != gdk_monitor_get_subpixel_layout (ex_monitor))
|
|
|
|
{
|
|
|
|
gdk_monitor_set_subpixel_layout (ex_monitor, gdk_monitor_get_subpixel_layout (m));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-05-13 02:44:06 +00:00
|
|
|
for (i = g_list_model_get_n_items (win32_display->monitors) - 1; i >= 0; i--)
|
2016-04-20 07:36:00 +00:00
|
|
|
{
|
|
|
|
GdkWin32Monitor *w32_ex_monitor;
|
|
|
|
GdkMonitor *ex_monitor;
|
|
|
|
|
2020-05-13 02:44:06 +00:00
|
|
|
w32_ex_monitor = GDK_WIN32_MONITOR (g_list_model_get_item (win32_display->monitors, i));
|
2016-04-20 07:36:00 +00:00
|
|
|
ex_monitor = GDK_MONITOR (w32_ex_monitor);
|
|
|
|
|
2023-09-19 16:46:41 +00:00
|
|
|
if (w32_ex_monitor->remove)
|
|
|
|
{
|
|
|
|
w32_ex_monitor->hmonitor = NULL;
|
|
|
|
g_list_store_remove (G_LIST_STORE (win32_display->monitors), i);
|
|
|
|
gdk_monitor_invalidate (ex_monitor);
|
|
|
|
}
|
2016-04-20 07:36:00 +00:00
|
|
|
|
2023-09-19 16:46:41 +00:00
|
|
|
g_object_unref (w32_ex_monitor);
|
2016-04-20 07:36:00 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
for (i = 0; i < new_monitors->len; i++)
|
|
|
|
{
|
|
|
|
GdkWin32Monitor *w32_m;
|
|
|
|
|
|
|
|
w32_m = GDK_WIN32_MONITOR (g_ptr_array_index (new_monitors, i));
|
|
|
|
|
|
|
|
if (!w32_m->add)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
if (i == 0)
|
2020-05-13 02:44:06 +00:00
|
|
|
g_list_store_insert (G_LIST_STORE (win32_display->monitors), 0, w32_m);
|
2016-04-20 07:36:00 +00:00
|
|
|
else
|
2020-05-13 02:44:06 +00:00
|
|
|
g_list_store_append (G_LIST_STORE (win32_display->monitors), w32_m);
|
2016-04-20 07:36:00 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
g_ptr_array_free (new_monitors, TRUE);
|
|
|
|
|
|
|
|
if (primary_to_move)
|
|
|
|
{
|
2020-05-13 02:44:06 +00:00
|
|
|
guint pos;
|
|
|
|
g_object_ref (primary_to_move);
|
|
|
|
if (g_list_store_find (G_LIST_STORE (win32_display->monitors), primary_to_move, &pos))
|
|
|
|
g_list_store_remove (G_LIST_STORE (win32_display->monitors), pos);
|
|
|
|
g_list_store_insert (G_LIST_STORE (win32_display->monitors), 0, primary_to_move);
|
|
|
|
g_object_unref (primary_to_move);
|
2016-04-20 07:36:00 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2015-05-13 07:45:40 +00:00
|
|
|
/**
|
|
|
|
* gdk_win32_display_set_cursor_theme:
|
2021-05-18 21:05:26 +00:00
|
|
|
* @display: (type GdkWin32Display): a `GdkDisplay`
|
2021-05-19 11:24:34 +00:00
|
|
|
* @name: (nullable): the name of the cursor theme to use, or %NULL
|
2021-05-18 21:05:26 +00:00
|
|
|
* to unset a previously set value
|
2015-05-13 07:45:40 +00:00
|
|
|
* @size: the cursor size to use, or 0 to keep the previous size
|
|
|
|
*
|
|
|
|
* Sets the cursor theme from which the images for cursor
|
|
|
|
* should be taken.
|
|
|
|
*
|
|
|
|
* If the windowing system supports it, existing cursors created
|
2021-05-18 21:05:26 +00:00
|
|
|
* with [ctor@Gdk.Cursor.new_from_name] are updated to reflect the theme
|
|
|
|
* change. Custom cursors constructed with [ctor@Gdk.Cursor.new_from_texture]
|
2020-08-05 19:42:27 +00:00
|
|
|
* will have to be handled by the application (GTK applications can
|
|
|
|
* learn about cursor theme changes by listening for change notification
|
2021-05-20 03:39:18 +00:00
|
|
|
* for the corresponding `GtkSetting`).
|
2015-05-13 07:45:40 +00:00
|
|
|
*/
|
|
|
|
void
|
|
|
|
gdk_win32_display_set_cursor_theme (GdkDisplay *display,
|
2020-07-24 18:40:36 +00:00
|
|
|
const char *name,
|
2020-07-24 13:54:49 +00:00
|
|
|
int size)
|
2015-05-13 07:45:40 +00:00
|
|
|
{
|
2020-07-24 13:54:49 +00:00
|
|
|
int cursor_size;
|
|
|
|
int w, h;
|
2015-05-13 07:45:40 +00:00
|
|
|
Win32CursorTheme *theme;
|
|
|
|
GdkWin32Display *win32_display = GDK_WIN32_DISPLAY (display);
|
|
|
|
|
|
|
|
g_assert (win32_display);
|
|
|
|
|
|
|
|
if (name == NULL)
|
|
|
|
name = "system";
|
|
|
|
|
|
|
|
w = GetSystemMetrics (SM_CXCURSOR);
|
|
|
|
h = GetSystemMetrics (SM_CYCURSOR);
|
|
|
|
|
|
|
|
/* We can load cursors of any size, but SetCursor() will scale them back
|
|
|
|
* to this value. It's possible to break that restrictions with SetSystemCursor(),
|
|
|
|
* but that will override cursors for the whole desktop session.
|
|
|
|
*/
|
|
|
|
cursor_size = (w == h) ? w : size;
|
|
|
|
|
|
|
|
if (win32_display->cursor_theme_name != NULL &&
|
|
|
|
g_strcmp0 (name, win32_display->cursor_theme_name) == 0 &&
|
|
|
|
win32_display->cursor_theme_size == cursor_size)
|
|
|
|
return;
|
|
|
|
|
|
|
|
theme = win32_cursor_theme_load (name, cursor_size);
|
|
|
|
if (theme == NULL)
|
|
|
|
{
|
|
|
|
g_warning ("Failed to load cursor theme %s", name);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (win32_display->cursor_theme)
|
|
|
|
{
|
|
|
|
win32_cursor_theme_destroy (win32_display->cursor_theme);
|
|
|
|
win32_display->cursor_theme = NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
win32_display->cursor_theme = theme;
|
|
|
|
g_free (win32_display->cursor_theme_name);
|
|
|
|
win32_display->cursor_theme_name = g_strdup (name);
|
|
|
|
win32_display->cursor_theme_size = cursor_size;
|
|
|
|
|
|
|
|
_gdk_win32_display_update_cursors (win32_display);
|
|
|
|
}
|
|
|
|
|
|
|
|
Win32CursorTheme *
|
|
|
|
_gdk_win32_display_get_cursor_theme (GdkWin32Display *win32_display)
|
|
|
|
{
|
|
|
|
Win32CursorTheme *theme;
|
|
|
|
|
|
|
|
g_assert (win32_display->cursor_theme_name);
|
|
|
|
|
|
|
|
theme = win32_display->cursor_theme;
|
|
|
|
if (!theme)
|
|
|
|
{
|
|
|
|
theme = win32_cursor_theme_load (win32_display->cursor_theme_name,
|
|
|
|
win32_display->cursor_theme_size);
|
|
|
|
if (theme == NULL)
|
|
|
|
{
|
|
|
|
g_warning ("Failed to load cursor theme %s",
|
|
|
|
win32_display->cursor_theme_name);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
win32_display->cursor_theme = theme;
|
|
|
|
}
|
|
|
|
|
|
|
|
return theme;
|
|
|
|
}
|
2003-12-08 22:43:51 +00:00
|
|
|
|
2011-01-02 10:51:25 +00:00
|
|
|
static gulong
|
|
|
|
gdk_win32_display_get_next_serial (GdkDisplay *display)
|
2009-02-14 18:23:54 +00:00
|
|
|
{
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2015-10-29 16:20:54 +00:00
|
|
|
static LRESULT CALLBACK
|
|
|
|
inner_display_change_window_procedure (HWND hwnd,
|
|
|
|
UINT message,
|
|
|
|
WPARAM wparam,
|
|
|
|
LPARAM lparam)
|
|
|
|
{
|
|
|
|
switch (message)
|
|
|
|
{
|
|
|
|
case WM_DESTROY:
|
|
|
|
{
|
|
|
|
PostQuitMessage (0);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
case WM_DISPLAYCHANGE:
|
|
|
|
{
|
2016-01-15 19:45:45 +00:00
|
|
|
GdkWin32Display *win32_display = GDK_WIN32_DISPLAY (_gdk_display);
|
|
|
|
|
2016-02-29 17:17:28 +00:00
|
|
|
_gdk_win32_screen_on_displaychange_event (GDK_WIN32_SCREEN (win32_display->screen));
|
2015-10-29 16:20:54 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
default:
|
|
|
|
/* Otherwise call DefWindowProcW(). */
|
|
|
|
GDK_NOTE (EVENTS, g_print (" DefWindowProcW"));
|
|
|
|
return DefWindowProc (hwnd, message, wparam, lparam);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static LRESULT CALLBACK
|
|
|
|
display_change_window_procedure (HWND hwnd,
|
|
|
|
UINT message,
|
|
|
|
WPARAM wparam,
|
|
|
|
LPARAM lparam)
|
|
|
|
{
|
|
|
|
LRESULT retval;
|
|
|
|
|
|
|
|
GDK_NOTE (EVENTS, g_print ("%s%*s%s %p",
|
|
|
|
(debug_indent > 0 ? "\n" : ""),
|
|
|
|
debug_indent, "",
|
|
|
|
_gdk_win32_message_to_string (message), hwnd));
|
|
|
|
debug_indent += 2;
|
|
|
|
retval = inner_display_change_window_procedure (hwnd, message, wparam, lparam);
|
|
|
|
debug_indent -= 2;
|
|
|
|
|
|
|
|
GDK_NOTE (EVENTS, g_print (" => %" G_GINT64_FORMAT "%s", (gint64) retval, (debug_indent == 0 ? "\n" : "")));
|
|
|
|
|
|
|
|
return retval;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Use a hidden window to be notified about display changes */
|
|
|
|
static void
|
|
|
|
register_display_change_notification (GdkDisplay *display)
|
|
|
|
{
|
|
|
|
GdkWin32Display *display_win32 = GDK_WIN32_DISPLAY (display);
|
|
|
|
WNDCLASS wclass = { 0, };
|
|
|
|
ATOM klass;
|
|
|
|
|
|
|
|
wclass.lpszClassName = "GdkDisplayChange";
|
|
|
|
wclass.lpfnWndProc = display_change_window_procedure;
|
2023-03-23 15:27:17 +00:00
|
|
|
wclass.hInstance = this_module ();
|
Split out WGL/EGL stuff and simplify things
This commit attempts to split GdkWin32GLContext into two parts, one for
WGL and the other for EGL (ANGLE), and attempts to simplify things a
bit, by:
* We are already creating a Win32 window to capture display changes,
so we can just use that to act as our dummy window that we use to
find out the pixel format that the system supports for WGL. We also
use it to obtain the dummy legacy WGL context that we will always
require to create our more advanced Core WGL contexts.
* Like what is done in X11, store up the WGL pixel format or the
EGLConfig in our GdkWin32Display.
* Ensure we do not create the dummy WGL context unnecessarily.
In this way, we can successfully create the WGL/EGL contexts, however
there are some issues at this point:
* For WGL, the code successfully initializes and realizes the WGL
Contexts, but for some reason things became invisible. When running
gtk4-demo, this can be verified by seeing the mouse cursor changing
when moved to spots where one can resize the window, although they
were invisible.
* For EGL, the code initializes EGL but could not realize the EGL
context as shaders failed to compile. It seems like the shader issue
is definitely outside the scope of this MR.
2021-07-14 09:46:31 +00:00
|
|
|
wclass.style = CS_OWNDC;
|
2015-10-29 16:20:54 +00:00
|
|
|
|
|
|
|
klass = RegisterClass (&wclass);
|
|
|
|
if (klass)
|
|
|
|
{
|
|
|
|
display_win32->hwnd = CreateWindow (MAKEINTRESOURCE (klass),
|
|
|
|
NULL, WS_POPUP,
|
|
|
|
0, 0, 0, 0, NULL, NULL,
|
2023-03-23 15:27:17 +00:00
|
|
|
this_module (), NULL);
|
2015-10-29 16:20:54 +00:00
|
|
|
if (!display_win32->hwnd)
|
|
|
|
{
|
2023-03-23 15:27:17 +00:00
|
|
|
UnregisterClass (MAKEINTRESOURCE (klass), this_module ());
|
2015-10-29 16:20:54 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2004-09-03 01:27:57 +00:00
|
|
|
GdkDisplay *
|
2020-07-24 18:40:36 +00:00
|
|
|
_gdk_win32_display_open (const char *display_name)
|
2004-09-03 01:27:57 +00:00
|
|
|
{
|
2016-01-15 19:45:45 +00:00
|
|
|
GdkWin32Display *win32_display;
|
|
|
|
|
2005-03-20 21:39:55 +00:00
|
|
|
GDK_NOTE (MISC, g_print ("gdk_display_open: %s\n", (display_name ? display_name : "NULL")));
|
|
|
|
|
|
|
|
if (display_name == NULL ||
|
|
|
|
g_ascii_strcasecmp (display_name,
|
|
|
|
gdk_display_get_name (_gdk_display)) == 0)
|
|
|
|
{
|
|
|
|
if (_gdk_display != NULL)
|
|
|
|
{
|
|
|
|
GDK_NOTE (MISC, g_print ("... return _gdk_display\n"));
|
|
|
|
return _gdk_display;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
GDK_NOTE (MISC, g_print ("... return NULL\n"));
|
|
|
|
return NULL;
|
|
|
|
}
|
2004-09-03 01:27:57 +00:00
|
|
|
|
2011-01-02 10:51:25 +00:00
|
|
|
_gdk_display = g_object_new (GDK_TYPE_WIN32_DISPLAY, NULL);
|
2016-01-15 19:45:45 +00:00
|
|
|
win32_display = GDK_WIN32_DISPLAY (_gdk_display);
|
|
|
|
|
|
|
|
win32_display->screen = g_object_new (GDK_TYPE_WIN32_SCREEN, NULL);
|
2004-09-03 01:27:57 +00:00
|
|
|
|
2016-03-05 18:02:15 +00:00
|
|
|
_gdk_events_init (_gdk_display);
|
2016-02-29 19:59:36 +00:00
|
|
|
|
2017-02-10 10:49:00 +00:00
|
|
|
_gdk_input_ignore_core = 0;
|
2016-02-29 19:59:36 +00:00
|
|
|
|
2017-11-24 16:56:42 +00:00
|
|
|
_gdk_device_manager = g_object_new (GDK_TYPE_DEVICE_MANAGER_WIN32,
|
|
|
|
NULL);
|
2017-11-30 05:38:20 +00:00
|
|
|
_gdk_device_manager->display = _gdk_display;
|
2016-02-29 19:59:36 +00:00
|
|
|
|
GDK W32: Test for IME correctly
ImmIsIME() doesn't work (always returns TRUE) since Vista.
Use ITfActiveLanguageProfileNotifySink to detect TSF changes,
which are equal to IME changes for us.
Also make sure that IMMultiContext re-loads the IM when keyboard layout
changes, otherwise there's a subtle bug that could happen:
* Run GTK application with non-IME layout (US, for example)
* Focus on an editable widget (GtkEntry, for example)
* IM Context is initialized to use the simple IM
* Switch to an IME layout (such as Korean)
* Start typing
* Since IME module is not loaded yet, keypresses are handled
by a default MS IME handler
* Once IME commits a character, GDK will get a WM_KEYDOWN,
which will trigger a GdkKeyEvent, which will be handled by
an event filter in IM Context, which will finally re-evaluate
its status and load IME, and only after that GTK will get
to handle IME by itself - but by that point input would
already be broken.
To avoid this we can emit a dummy event (with Void keyval),
which will cause IM Context to load the appropriate module
immediately.
2019-03-22 15:10:02 +00:00
|
|
|
_gdk_win32_lang_notification_init ();
|
2018-03-24 16:27:11 +00:00
|
|
|
_gdk_drag_init ();
|
|
|
|
|
|
|
|
_gdk_display->clipboard = gdk_win32_clipboard_new (_gdk_display);
|
|
|
|
_gdk_display->primary_clipboard = gdk_clipboard_new (_gdk_display);
|
Changes multihead reorganizing code for win32 support, mostly from a patch
Wed Jun 5 18:34:47 2002 Owen Taylor <otaylor@redhat.com>
Changes multihead reorganizing code for win32 support,
mostly from a patch by Hans Breuer.
* gdk/gdkcolor.c gdk/x11/gdkcolor-x11.c gdk/gdkcursor.c
gdk/x11/gdkcursor-x11.c gdk/gdkevents.c gdk/x11/gdkevents-x11.c
gdk/gdkfont.c gdk/x11/gdkfont-x11.c gdk/gdkkeys.c
gdk/x11/gdkkeys-x11.c gdk/gdkimage.c gdk/x11/gdkimage-x11.c
gdk/gdkscreen.c gdk/x11/gdkmain-x11.c
gdk/gdkdisplay.c gdk/gdkevents-x11.c gdk/gdkpango.c
gdk/x11/gdkpango-x11.c gdk/gdkselection.c
gdk/x11/gdkselection-x11.c gdk/gdkwindow.c
gdk/x11/gdkwindow-x11.c gdk/gdkvisual.c gdk/x11/gdkvisual-x11.c:
Move port-independent singlehead wrapper functions into
port-independent part of GDK. (#80009)
* gdk/win32/gdkcolor-win32.c gdk/win32/gdkcursor-win32.c
gdk/win32/gdkevents-win32.c gdk/win32/gdkfont-win32.c
gdk/win32/gdkimage-win32.c gdk/win32/gdkkeys-win32.c
gdk/win32/gdkmain-win32.c gdk/win32/gdkproperty-win32.c
gdk/win32/gdkselection-win32.c gdk/win32/gkwindow-win32.c:
Turn singlehead functions into "multihead" functions that ignore
their GdkDisplay or GdkScreen arguments.
* gdk/win32/gdkdrawable-win32.c gdk/win32/gdkevents-win32.c
gdk/win32/gdkinput-win32.c gdk/win32/gdkprivate-win32.h:
Misc multihead-compatibility changes.
* gtk/gtk.def gdk/gdk.def: Update for multihead functions.
* gdk/gdkcolormap.h gdk/gdkvisual.h gdk/x11/gdkcolormap-x11.c
gdk/x11/gdkvisual-x11.c: Remove the screen fields
from the public parts of the colormap/visual structures, add accessors
instead.
* gdk/gdkpixbuf-render.c gdk/gdkpixmap.c gdk/gdkrgb.c
gdk/x11/gdkcolormap-x11.c gdk/x11/gdkimage-x11.c
gdk/x11/gdkimage-x11.c gdk/x11/gdkprivate-x11.h gtk/gtkgc.c
gtk/gtkstyle.c gtk/gtkwidget.c: Use accessors to get the screen
for colormaps, visuals; move the fields into the private
structures for the x11 backend.
* gdk/gdkdisplay.[ch] gdk/x11/gdkdisplay-x11.[ch]
gdk/gdkscreen.[ch] gdk/x11/gdkscreen-x11.c:
Remove virtualization of screen and display functions.
(#79990, patch from Erwann Chenede)
* gdk/win32/gdkdisplay-x11.c gdk/win32/gdkscreen-win32.c
gdk/win32/{Makefile.am, makefile.msc, makefile.mingw}:
New files containing stub implementations of Display,
Screen functions.
* gdk/x11/gdkscreen-x11.[ch] gdk/x11/gdkdisplay-x11.[ch]
gdk/x11/gdkx.h: Clean up function exports and what
headers they are in. (#79954)
* gdk/x11/gdkx.h: Fix macro that was referring to a non-existant
screen->screen_num. (In the patch for #79972, Erwann Chenede)
* gdk/gdkscreen.c gdk/gdkwindow.c gdk/x11/gdkinternals.h
gdk/x11/gdkscreen-x11.c: Fix gdk_screen_get_window_at_pointer()
to use window hooks. (#79972, patch partly from Erwann Chenede)
* gdk/x11/gdkdisplay-x11.c gdk/x11/gdkevents-x11.c: Fix
some warnings.
2002-06-06 00:26:42 +00:00
|
|
|
|
2005-09-08 22:45:40 +00:00
|
|
|
/* Precalculate display name */
|
|
|
|
(void) gdk_display_get_name (_gdk_display);
|
|
|
|
|
2015-10-29 16:20:54 +00:00
|
|
|
register_display_change_notification (_gdk_display);
|
|
|
|
|
2013-04-17 21:59:21 +00:00
|
|
|
g_signal_emit_by_name (_gdk_display, "opened");
|
|
|
|
|
2005-03-20 21:39:55 +00:00
|
|
|
GDK_NOTE (MISC, g_print ("... _gdk_display now set up\n"));
|
|
|
|
|
Changes multihead reorganizing code for win32 support, mostly from a patch
Wed Jun 5 18:34:47 2002 Owen Taylor <otaylor@redhat.com>
Changes multihead reorganizing code for win32 support,
mostly from a patch by Hans Breuer.
* gdk/gdkcolor.c gdk/x11/gdkcolor-x11.c gdk/gdkcursor.c
gdk/x11/gdkcursor-x11.c gdk/gdkevents.c gdk/x11/gdkevents-x11.c
gdk/gdkfont.c gdk/x11/gdkfont-x11.c gdk/gdkkeys.c
gdk/x11/gdkkeys-x11.c gdk/gdkimage.c gdk/x11/gdkimage-x11.c
gdk/gdkscreen.c gdk/x11/gdkmain-x11.c
gdk/gdkdisplay.c gdk/gdkevents-x11.c gdk/gdkpango.c
gdk/x11/gdkpango-x11.c gdk/gdkselection.c
gdk/x11/gdkselection-x11.c gdk/gdkwindow.c
gdk/x11/gdkwindow-x11.c gdk/gdkvisual.c gdk/x11/gdkvisual-x11.c:
Move port-independent singlehead wrapper functions into
port-independent part of GDK. (#80009)
* gdk/win32/gdkcolor-win32.c gdk/win32/gdkcursor-win32.c
gdk/win32/gdkevents-win32.c gdk/win32/gdkfont-win32.c
gdk/win32/gdkimage-win32.c gdk/win32/gdkkeys-win32.c
gdk/win32/gdkmain-win32.c gdk/win32/gdkproperty-win32.c
gdk/win32/gdkselection-win32.c gdk/win32/gkwindow-win32.c:
Turn singlehead functions into "multihead" functions that ignore
their GdkDisplay or GdkScreen arguments.
* gdk/win32/gdkdrawable-win32.c gdk/win32/gdkevents-win32.c
gdk/win32/gdkinput-win32.c gdk/win32/gdkprivate-win32.h:
Misc multihead-compatibility changes.
* gtk/gtk.def gdk/gdk.def: Update for multihead functions.
* gdk/gdkcolormap.h gdk/gdkvisual.h gdk/x11/gdkcolormap-x11.c
gdk/x11/gdkvisual-x11.c: Remove the screen fields
from the public parts of the colormap/visual structures, add accessors
instead.
* gdk/gdkpixbuf-render.c gdk/gdkpixmap.c gdk/gdkrgb.c
gdk/x11/gdkcolormap-x11.c gdk/x11/gdkimage-x11.c
gdk/x11/gdkimage-x11.c gdk/x11/gdkprivate-x11.h gtk/gtkgc.c
gtk/gtkstyle.c gtk/gtkwidget.c: Use accessors to get the screen
for colormaps, visuals; move the fields into the private
structures for the x11 backend.
* gdk/gdkdisplay.[ch] gdk/x11/gdkdisplay-x11.[ch]
gdk/gdkscreen.[ch] gdk/x11/gdkscreen-x11.c:
Remove virtualization of screen and display functions.
(#79990, patch from Erwann Chenede)
* gdk/win32/gdkdisplay-x11.c gdk/win32/gdkscreen-win32.c
gdk/win32/{Makefile.am, makefile.msc, makefile.mingw}:
New files containing stub implementations of Display,
Screen functions.
* gdk/x11/gdkscreen-x11.[ch] gdk/x11/gdkdisplay-x11.[ch]
gdk/x11/gdkx.h: Clean up function exports and what
headers they are in. (#79954)
* gdk/x11/gdkx.h: Fix macro that was referring to a non-existant
screen->screen_num. (In the patch for #79972, Erwann Chenede)
* gdk/gdkscreen.c gdk/gdkwindow.c gdk/x11/gdkinternals.h
gdk/x11/gdkscreen-x11.c: Fix gdk_screen_get_window_at_pointer()
to use window hooks. (#79972, patch partly from Erwann Chenede)
* gdk/x11/gdkdisplay-x11.c gdk/x11/gdkevents-x11.c: Fix
some warnings.
2002-06-06 00:26:42 +00:00
|
|
|
return _gdk_display;
|
|
|
|
}
|
|
|
|
|
2011-01-02 10:51:25 +00:00
|
|
|
G_DEFINE_TYPE (GdkWin32Display, gdk_win32_display, GDK_TYPE_DISPLAY)
|
|
|
|
|
2020-07-24 18:40:36 +00:00
|
|
|
static const char *
|
2011-01-02 10:51:25 +00:00
|
|
|
gdk_win32_display_get_name (GdkDisplay *display)
|
Changes multihead reorganizing code for win32 support, mostly from a patch
Wed Jun 5 18:34:47 2002 Owen Taylor <otaylor@redhat.com>
Changes multihead reorganizing code for win32 support,
mostly from a patch by Hans Breuer.
* gdk/gdkcolor.c gdk/x11/gdkcolor-x11.c gdk/gdkcursor.c
gdk/x11/gdkcursor-x11.c gdk/gdkevents.c gdk/x11/gdkevents-x11.c
gdk/gdkfont.c gdk/x11/gdkfont-x11.c gdk/gdkkeys.c
gdk/x11/gdkkeys-x11.c gdk/gdkimage.c gdk/x11/gdkimage-x11.c
gdk/gdkscreen.c gdk/x11/gdkmain-x11.c
gdk/gdkdisplay.c gdk/gdkevents-x11.c gdk/gdkpango.c
gdk/x11/gdkpango-x11.c gdk/gdkselection.c
gdk/x11/gdkselection-x11.c gdk/gdkwindow.c
gdk/x11/gdkwindow-x11.c gdk/gdkvisual.c gdk/x11/gdkvisual-x11.c:
Move port-independent singlehead wrapper functions into
port-independent part of GDK. (#80009)
* gdk/win32/gdkcolor-win32.c gdk/win32/gdkcursor-win32.c
gdk/win32/gdkevents-win32.c gdk/win32/gdkfont-win32.c
gdk/win32/gdkimage-win32.c gdk/win32/gdkkeys-win32.c
gdk/win32/gdkmain-win32.c gdk/win32/gdkproperty-win32.c
gdk/win32/gdkselection-win32.c gdk/win32/gkwindow-win32.c:
Turn singlehead functions into "multihead" functions that ignore
their GdkDisplay or GdkScreen arguments.
* gdk/win32/gdkdrawable-win32.c gdk/win32/gdkevents-win32.c
gdk/win32/gdkinput-win32.c gdk/win32/gdkprivate-win32.h:
Misc multihead-compatibility changes.
* gtk/gtk.def gdk/gdk.def: Update for multihead functions.
* gdk/gdkcolormap.h gdk/gdkvisual.h gdk/x11/gdkcolormap-x11.c
gdk/x11/gdkvisual-x11.c: Remove the screen fields
from the public parts of the colormap/visual structures, add accessors
instead.
* gdk/gdkpixbuf-render.c gdk/gdkpixmap.c gdk/gdkrgb.c
gdk/x11/gdkcolormap-x11.c gdk/x11/gdkimage-x11.c
gdk/x11/gdkimage-x11.c gdk/x11/gdkprivate-x11.h gtk/gtkgc.c
gtk/gtkstyle.c gtk/gtkwidget.c: Use accessors to get the screen
for colormaps, visuals; move the fields into the private
structures for the x11 backend.
* gdk/gdkdisplay.[ch] gdk/x11/gdkdisplay-x11.[ch]
gdk/gdkscreen.[ch] gdk/x11/gdkscreen-x11.c:
Remove virtualization of screen and display functions.
(#79990, patch from Erwann Chenede)
* gdk/win32/gdkdisplay-x11.c gdk/win32/gdkscreen-win32.c
gdk/win32/{Makefile.am, makefile.msc, makefile.mingw}:
New files containing stub implementations of Display,
Screen functions.
* gdk/x11/gdkscreen-x11.[ch] gdk/x11/gdkdisplay-x11.[ch]
gdk/x11/gdkx.h: Clean up function exports and what
headers they are in. (#79954)
* gdk/x11/gdkx.h: Fix macro that was referring to a non-existant
screen->screen_num. (In the patch for #79972, Erwann Chenede)
* gdk/gdkscreen.c gdk/gdkwindow.c gdk/x11/gdkinternals.h
gdk/x11/gdkscreen-x11.c: Fix gdk_screen_get_window_at_pointer()
to use window hooks. (#79972, patch partly from Erwann Chenede)
* gdk/x11/gdkdisplay-x11.c gdk/x11/gdkevents-x11.c: Fix
some warnings.
2002-06-06 00:26:42 +00:00
|
|
|
{
|
2005-03-20 21:39:55 +00:00
|
|
|
HDESK hdesk = GetThreadDesktop (GetCurrentThreadId ());
|
|
|
|
char dummy;
|
|
|
|
char *desktop_name;
|
|
|
|
HWINSTA hwinsta = GetProcessWindowStation ();
|
|
|
|
char *window_station_name;
|
|
|
|
DWORD n;
|
2008-06-11 16:05:28 +00:00
|
|
|
DWORD session_id;
|
2005-03-20 21:39:55 +00:00
|
|
|
char *display_name;
|
2005-09-08 22:45:40 +00:00
|
|
|
static const char *display_name_cache = NULL;
|
2009-04-06 12:10:35 +00:00
|
|
|
typedef BOOL (WINAPI *PFN_ProcessIdToSessionId) (DWORD, DWORD *);
|
2008-06-13 08:36:26 +00:00
|
|
|
PFN_ProcessIdToSessionId processIdToSessionId;
|
2005-09-08 22:45:40 +00:00
|
|
|
|
|
|
|
g_return_val_if_fail (GDK_IS_DISPLAY (display), NULL);
|
2011-06-09 18:45:20 +00:00
|
|
|
|
2005-09-08 22:45:40 +00:00
|
|
|
if (display_name_cache != NULL)
|
|
|
|
return display_name_cache;
|
2005-03-20 21:39:55 +00:00
|
|
|
|
|
|
|
n = 0;
|
|
|
|
GetUserObjectInformation (hdesk, UOI_NAME, &dummy, 0, &n);
|
|
|
|
if (n == 0)
|
|
|
|
desktop_name = "Default";
|
|
|
|
else
|
|
|
|
{
|
|
|
|
n++;
|
|
|
|
desktop_name = g_alloca (n + 1);
|
|
|
|
memset (desktop_name, 0, n + 1);
|
|
|
|
|
|
|
|
if (!GetUserObjectInformation (hdesk, UOI_NAME, desktop_name, n, &n))
|
|
|
|
desktop_name = "Default";
|
|
|
|
}
|
|
|
|
|
|
|
|
n = 0;
|
|
|
|
GetUserObjectInformation (hwinsta, UOI_NAME, &dummy, 0, &n);
|
|
|
|
if (n == 0)
|
|
|
|
window_station_name = "WinSta0";
|
|
|
|
else
|
|
|
|
{
|
|
|
|
n++;
|
|
|
|
window_station_name = g_alloca (n + 1);
|
|
|
|
memset (window_station_name, 0, n + 1);
|
|
|
|
|
|
|
|
if (!GetUserObjectInformation (hwinsta, UOI_NAME, window_station_name, n, &n))
|
|
|
|
window_station_name = "WinSta0";
|
|
|
|
}
|
|
|
|
|
2008-06-13 08:36:26 +00:00
|
|
|
processIdToSessionId = (PFN_ProcessIdToSessionId) GetProcAddress (GetModuleHandle ("kernel32.dll"), "ProcessIdToSessionId");
|
|
|
|
if (!processIdToSessionId || !processIdToSessionId (GetCurrentProcessId (), &session_id))
|
2008-06-11 16:05:28 +00:00
|
|
|
session_id = 0;
|
|
|
|
|
|
|
|
display_name = g_strdup_printf ("%ld\\%s\\%s",
|
|
|
|
session_id,
|
|
|
|
window_station_name,
|
2005-03-20 21:39:55 +00:00
|
|
|
desktop_name);
|
|
|
|
|
2011-01-02 10:51:25 +00:00
|
|
|
GDK_NOTE (MISC, g_print ("gdk_win32_display_get_name: %s\n", display_name));
|
2005-03-20 21:39:55 +00:00
|
|
|
|
2005-09-08 22:45:40 +00:00
|
|
|
display_name_cache = display_name;
|
2005-03-20 21:39:55 +00:00
|
|
|
|
2005-09-08 22:45:40 +00:00
|
|
|
return display_name_cache;
|
Changes multihead reorganizing code for win32 support, mostly from a patch
Wed Jun 5 18:34:47 2002 Owen Taylor <otaylor@redhat.com>
Changes multihead reorganizing code for win32 support,
mostly from a patch by Hans Breuer.
* gdk/gdkcolor.c gdk/x11/gdkcolor-x11.c gdk/gdkcursor.c
gdk/x11/gdkcursor-x11.c gdk/gdkevents.c gdk/x11/gdkevents-x11.c
gdk/gdkfont.c gdk/x11/gdkfont-x11.c gdk/gdkkeys.c
gdk/x11/gdkkeys-x11.c gdk/gdkimage.c gdk/x11/gdkimage-x11.c
gdk/gdkscreen.c gdk/x11/gdkmain-x11.c
gdk/gdkdisplay.c gdk/gdkevents-x11.c gdk/gdkpango.c
gdk/x11/gdkpango-x11.c gdk/gdkselection.c
gdk/x11/gdkselection-x11.c gdk/gdkwindow.c
gdk/x11/gdkwindow-x11.c gdk/gdkvisual.c gdk/x11/gdkvisual-x11.c:
Move port-independent singlehead wrapper functions into
port-independent part of GDK. (#80009)
* gdk/win32/gdkcolor-win32.c gdk/win32/gdkcursor-win32.c
gdk/win32/gdkevents-win32.c gdk/win32/gdkfont-win32.c
gdk/win32/gdkimage-win32.c gdk/win32/gdkkeys-win32.c
gdk/win32/gdkmain-win32.c gdk/win32/gdkproperty-win32.c
gdk/win32/gdkselection-win32.c gdk/win32/gkwindow-win32.c:
Turn singlehead functions into "multihead" functions that ignore
their GdkDisplay or GdkScreen arguments.
* gdk/win32/gdkdrawable-win32.c gdk/win32/gdkevents-win32.c
gdk/win32/gdkinput-win32.c gdk/win32/gdkprivate-win32.h:
Misc multihead-compatibility changes.
* gtk/gtk.def gdk/gdk.def: Update for multihead functions.
* gdk/gdkcolormap.h gdk/gdkvisual.h gdk/x11/gdkcolormap-x11.c
gdk/x11/gdkvisual-x11.c: Remove the screen fields
from the public parts of the colormap/visual structures, add accessors
instead.
* gdk/gdkpixbuf-render.c gdk/gdkpixmap.c gdk/gdkrgb.c
gdk/x11/gdkcolormap-x11.c gdk/x11/gdkimage-x11.c
gdk/x11/gdkimage-x11.c gdk/x11/gdkprivate-x11.h gtk/gtkgc.c
gtk/gtkstyle.c gtk/gtkwidget.c: Use accessors to get the screen
for colormaps, visuals; move the fields into the private
structures for the x11 backend.
* gdk/gdkdisplay.[ch] gdk/x11/gdkdisplay-x11.[ch]
gdk/gdkscreen.[ch] gdk/x11/gdkscreen-x11.c:
Remove virtualization of screen and display functions.
(#79990, patch from Erwann Chenede)
* gdk/win32/gdkdisplay-x11.c gdk/win32/gdkscreen-win32.c
gdk/win32/{Makefile.am, makefile.msc, makefile.mingw}:
New files containing stub implementations of Display,
Screen functions.
* gdk/x11/gdkscreen-x11.[ch] gdk/x11/gdkdisplay-x11.[ch]
gdk/x11/gdkx.h: Clean up function exports and what
headers they are in. (#79954)
* gdk/x11/gdkx.h: Fix macro that was referring to a non-existant
screen->screen_num. (In the patch for #79972, Erwann Chenede)
* gdk/gdkscreen.c gdk/gdkwindow.c gdk/x11/gdkinternals.h
gdk/x11/gdkscreen-x11.c: Fix gdk_screen_get_window_at_pointer()
to use window hooks. (#79972, patch partly from Erwann Chenede)
* gdk/x11/gdkdisplay-x11.c gdk/x11/gdkevents-x11.c: Fix
some warnings.
2002-06-06 00:26:42 +00:00
|
|
|
}
|
|
|
|
|
2011-01-02 10:51:25 +00:00
|
|
|
static void
|
|
|
|
gdk_win32_display_beep (GdkDisplay *display)
|
|
|
|
{
|
|
|
|
g_return_if_fail (display == gdk_display_get_default());
|
|
|
|
if (!MessageBeep (-1))
|
|
|
|
Beep(1000, 50);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
gdk_win32_display_flush (GdkDisplay * display)
|
|
|
|
{
|
|
|
|
g_return_if_fail (display == _gdk_display);
|
|
|
|
|
|
|
|
GdiFlush ();
|
|
|
|
}
|
|
|
|
|
2011-10-27 14:56:40 +00:00
|
|
|
static void
|
|
|
|
gdk_win32_display_sync (GdkDisplay * display)
|
|
|
|
{
|
|
|
|
g_return_if_fail (display == _gdk_display);
|
|
|
|
|
|
|
|
GdiFlush ();
|
|
|
|
}
|
|
|
|
|
2011-01-02 10:51:25 +00:00
|
|
|
static void
|
|
|
|
gdk_win32_display_dispose (GObject *object)
|
|
|
|
{
|
2015-10-29 16:20:54 +00:00
|
|
|
GdkWin32Display *display_win32 = GDK_WIN32_DISPLAY (object);
|
|
|
|
|
gdkglcontext-win32-wgl.c: Fix using wglChoosePixelFormatARB()
If we are querying the best supported pixel format for our HDC via
wglChoosePixelFormatARB() (i.e. we have the WGL_ARB_pixel_format extension),
it may return a pixel format that is different from the pixel format that we
used for the dummy context that we have setup, in order to, well, run
wglChoosePixelFormatARB(), which sadly requires a WGL context (HGLRC) to be
current in order to use it, which means the dummy HDC already has a pixel
format that has been set (notice that each HDC is only allowed to have its
pixel format to be set *once*). This is notably the case on Intel display
drivers.
Since we are emulating surfaceless GL contexts, we are using the dummy GL
context (and thus dummy HDC that is derived from the notification HWND used in
GdkWin32Display) for doing that, we would get into trouble if th actual HDC
from the GdkWin32Surface has a different pixel format set.
So, as a result, in order to fix this situation, we do the following:
* Create yet another dummy HWND in order to grab the HDC to query for the
capabilities the GL drivers support, and to call wglChoosePixelFormatARB() as
appropriate (or ChoosePixelFormat()) for the final pixel format that we use.
* Ditch the dummy GL context, HDC and HWND after obtaining the pixel format.
* Then set the final pixel format that we obtained onto the HDC that is derived
from the HWND used in GdkWin32Display for notifications, which will become our
new dummy HDC.
* Create a new dummy HGLRC for use with the new dummy HDC to emulate surfaceless
GL support.
2023-05-03 09:58:54 +00:00
|
|
|
if (display_win32->dummy_context_wgl.hglrc != NULL)
|
2015-11-13 11:54:54 +00:00
|
|
|
{
|
gdkglcontext-win32-wgl.c: Fix using wglChoosePixelFormatARB()
If we are querying the best supported pixel format for our HDC via
wglChoosePixelFormatARB() (i.e. we have the WGL_ARB_pixel_format extension),
it may return a pixel format that is different from the pixel format that we
used for the dummy context that we have setup, in order to, well, run
wglChoosePixelFormatARB(), which sadly requires a WGL context (HGLRC) to be
current in order to use it, which means the dummy HDC already has a pixel
format that has been set (notice that each HDC is only allowed to have its
pixel format to be set *once*). This is notably the case on Intel display
drivers.
Since we are emulating surfaceless GL contexts, we are using the dummy GL
context (and thus dummy HDC that is derived from the notification HWND used in
GdkWin32Display) for doing that, we would get into trouble if th actual HDC
from the GdkWin32Surface has a different pixel format set.
So, as a result, in order to fix this situation, we do the following:
* Create yet another dummy HWND in order to grab the HDC to query for the
capabilities the GL drivers support, and to call wglChoosePixelFormatARB() as
appropriate (or ChoosePixelFormat()) for the final pixel format that we use.
* Ditch the dummy GL context, HDC and HWND after obtaining the pixel format.
* Then set the final pixel format that we obtained onto the HDC that is derived
from the HWND used in GdkWin32Display for notifications, which will become our
new dummy HDC.
* Create a new dummy HGLRC for use with the new dummy HDC to emulate surfaceless
GL support.
2023-05-03 09:58:54 +00:00
|
|
|
wglMakeCurrent (NULL, NULL);
|
|
|
|
wglDeleteContext (display_win32->dummy_context_wgl.hglrc);
|
|
|
|
display_win32->dummy_context_wgl.hglrc = NULL;
|
|
|
|
}
|
Split out WGL/EGL stuff and simplify things
This commit attempts to split GdkWin32GLContext into two parts, one for
WGL and the other for EGL (ANGLE), and attempts to simplify things a
bit, by:
* We are already creating a Win32 window to capture display changes,
so we can just use that to act as our dummy window that we use to
find out the pixel format that the system supports for WGL. We also
use it to obtain the dummy legacy WGL context that we will always
require to create our more advanced Core WGL contexts.
* Like what is done in X11, store up the WGL pixel format or the
EGLConfig in our GdkWin32Display.
* Ensure we do not create the dummy WGL context unnecessarily.
In this way, we can successfully create the WGL/EGL contexts, however
there are some issues at this point:
* For WGL, the code successfully initializes and realizes the WGL
Contexts, but for some reason things became invisible. When running
gtk4-demo, this can be verified by seeing the mouse cursor changing
when moved to spots where one can resize the window, although they
were invisible.
* For EGL, the code initializes EGL but could not realize the EGL
context as shaders failed to compile. It seems like the shader issue
is definitely outside the scope of this MR.
2021-07-14 09:46:31 +00:00
|
|
|
|
gdkglcontext-win32-wgl.c: Fix using wglChoosePixelFormatARB()
If we are querying the best supported pixel format for our HDC via
wglChoosePixelFormatARB() (i.e. we have the WGL_ARB_pixel_format extension),
it may return a pixel format that is different from the pixel format that we
used for the dummy context that we have setup, in order to, well, run
wglChoosePixelFormatARB(), which sadly requires a WGL context (HGLRC) to be
current in order to use it, which means the dummy HDC already has a pixel
format that has been set (notice that each HDC is only allowed to have its
pixel format to be set *once*). This is notably the case on Intel display
drivers.
Since we are emulating surfaceless GL contexts, we are using the dummy GL
context (and thus dummy HDC that is derived from the notification HWND used in
GdkWin32Display) for doing that, we would get into trouble if th actual HDC
from the GdkWin32Surface has a different pixel format set.
So, as a result, in order to fix this situation, we do the following:
* Create yet another dummy HWND in order to grab the HDC to query for the
capabilities the GL drivers support, and to call wglChoosePixelFormatARB() as
appropriate (or ChoosePixelFormat()) for the final pixel format that we use.
* Ditch the dummy GL context, HDC and HWND after obtaining the pixel format.
* Then set the final pixel format that we obtained onto the HDC that is derived
from the HWND used in GdkWin32Display for notifications, which will become our
new dummy HDC.
* Create a new dummy HGLRC for use with the new dummy HDC to emulate surfaceless
GL support.
2023-05-03 09:58:54 +00:00
|
|
|
if (display_win32->hwnd != NULL)
|
|
|
|
{
|
2015-11-13 11:54:54 +00:00
|
|
|
DestroyWindow (display_win32->hwnd);
|
|
|
|
display_win32->hwnd = NULL;
|
|
|
|
}
|
|
|
|
|
GDK-Win32/4.0: Enable HiDPI support for Windows
This enables HiDPI support for GTK+ on Windows, so that the
fonts and window look better on HiDPI displays. Notes for the current
work:
-The DPI awareness enabling can be disabled if and only if an application
manifest is not embedded in the app to enable DPI awareness AND a user
compatibility setting is not set to limit DPI awareness for the app, via
the envvar GDK_WIN32_DISABLE_HIDPI. The app manifest/user setting for
DPI awareness will always win against the envvar, and so the HiDPI items
will be always setup in such scenarios, unless DPI awareness is disabled.
-Both automatic detection for the scaling factor and setting the scale
factor using the GDK_SCALE envvar are supported, where the envvar takes
precedence, which will therefore disable automatic scaling when
resolution changes.
-We now default to a per-system DPI awareness model, which means that we
do not handle WM_DPICHANGED, unless one sets the
GDK_WIN32_PER_MONITOR_HIDPI envvar, where notes for it are in the
following point.
-Automatic scaling during WM_DISPLAYCHANGE is handled (DPI setting change of
current monitor) is now supported. WM_DPICHANGED is handled as well,
except that the window positioning during the change of scaling still
needs to be refined, a change in GDK itself may be required for this.
-I am unable to test the wintab items because I don't have such devices
around.
https://bugzilla.gnome.org/show_bug.cgi?id=768081
2016-06-27 05:16:43 +00:00
|
|
|
if (display_win32->have_at_least_win81)
|
|
|
|
{
|
|
|
|
if (display_win32->shcore_funcs.hshcore != NULL)
|
|
|
|
{
|
|
|
|
FreeLibrary (display_win32->shcore_funcs.hshcore);
|
|
|
|
display_win32->shcore_funcs.hshcore = NULL;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-11-12 14:59:43 +00:00
|
|
|
G_OBJECT_CLASS (gdk_win32_display_parent_class)->dispose (object);
|
2011-01-02 10:51:25 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
gdk_win32_display_finalize (GObject *object)
|
|
|
|
{
|
2015-05-13 07:45:40 +00:00
|
|
|
GdkWin32Display *display_win32 = GDK_WIN32_DISPLAY (object);
|
|
|
|
|
|
|
|
_gdk_win32_display_finalize_cursors (display_win32);
|
2015-12-15 20:25:25 +00:00
|
|
|
_gdk_win32_dnd_exit ();
|
GDK W32: Test for IME correctly
ImmIsIME() doesn't work (always returns TRUE) since Vista.
Use ITfActiveLanguageProfileNotifySink to detect TSF changes,
which are equal to IME changes for us.
Also make sure that IMMultiContext re-loads the IM when keyboard layout
changes, otherwise there's a subtle bug that could happen:
* Run GTK application with non-IME layout (US, for example)
* Focus on an editable widget (GtkEntry, for example)
* IM Context is initialized to use the simple IM
* Switch to an IME layout (such as Korean)
* Start typing
* Since IME module is not loaded yet, keypresses are handled
by a default MS IME handler
* Once IME commits a character, GDK will get a WM_KEYDOWN,
which will trigger a GdkKeyEvent, which will be handled by
an event filter in IM Context, which will finally re-evaluate
its status and load IME, and only after that GTK will get
to handle IME by itself - but by that point input would
already be broken.
To avoid this we can emit a dummy event (with Void keyval),
which will cause IM Context to load the appropriate module
immediately.
2019-03-22 15:10:02 +00:00
|
|
|
_gdk_win32_lang_notification_exit ();
|
2015-05-13 07:45:40 +00:00
|
|
|
|
2020-05-13 02:44:06 +00:00
|
|
|
g_list_store_remove_all (G_LIST_STORE (display_win32->monitors));
|
|
|
|
g_object_unref (display_win32->monitors);
|
2016-04-20 07:36:00 +00:00
|
|
|
|
2018-03-24 16:39:13 +00:00
|
|
|
while (display_win32->filters)
|
|
|
|
_gdk_win32_message_filter_unref (display_win32, display_win32->filters->data);
|
|
|
|
|
2015-05-13 07:45:40 +00:00
|
|
|
G_OBJECT_CLASS (gdk_win32_display_parent_class)->finalize (object);
|
2011-01-02 10:51:25 +00:00
|
|
|
}
|
|
|
|
|
GDK-Win32/4.0: Enable HiDPI support for Windows
This enables HiDPI support for GTK+ on Windows, so that the
fonts and window look better on HiDPI displays. Notes for the current
work:
-The DPI awareness enabling can be disabled if and only if an application
manifest is not embedded in the app to enable DPI awareness AND a user
compatibility setting is not set to limit DPI awareness for the app, via
the envvar GDK_WIN32_DISABLE_HIDPI. The app manifest/user setting for
DPI awareness will always win against the envvar, and so the HiDPI items
will be always setup in such scenarios, unless DPI awareness is disabled.
-Both automatic detection for the scaling factor and setting the scale
factor using the GDK_SCALE envvar are supported, where the envvar takes
precedence, which will therefore disable automatic scaling when
resolution changes.
-We now default to a per-system DPI awareness model, which means that we
do not handle WM_DPICHANGED, unless one sets the
GDK_WIN32_PER_MONITOR_HIDPI envvar, where notes for it are in the
following point.
-Automatic scaling during WM_DISPLAYCHANGE is handled (DPI setting change of
current monitor) is now supported. WM_DPICHANGED is handled as well,
except that the window positioning during the change of scaling still
needs to be refined, a change in GDK itself may be required for this.
-I am unable to test the wintab items because I don't have such devices
around.
https://bugzilla.gnome.org/show_bug.cgi?id=768081
2016-06-27 05:16:43 +00:00
|
|
|
static void
|
|
|
|
_gdk_win32_enable_hidpi (GdkWin32Display *display)
|
|
|
|
{
|
|
|
|
gboolean check_for_dpi_awareness = FALSE;
|
|
|
|
gboolean have_hpi_disable_envvar = FALSE;
|
|
|
|
|
2019-12-04 10:41:05 +00:00
|
|
|
HMODULE user32;
|
|
|
|
user32 = GetModuleHandleW (L"user32.dll");
|
|
|
|
|
GDK-Win32/4.0: Enable HiDPI support for Windows
This enables HiDPI support for GTK+ on Windows, so that the
fonts and window look better on HiDPI displays. Notes for the current
work:
-The DPI awareness enabling can be disabled if and only if an application
manifest is not embedded in the app to enable DPI awareness AND a user
compatibility setting is not set to limit DPI awareness for the app, via
the envvar GDK_WIN32_DISABLE_HIDPI. The app manifest/user setting for
DPI awareness will always win against the envvar, and so the HiDPI items
will be always setup in such scenarios, unless DPI awareness is disabled.
-Both automatic detection for the scaling factor and setting the scale
factor using the GDK_SCALE envvar are supported, where the envvar takes
precedence, which will therefore disable automatic scaling when
resolution changes.
-We now default to a per-system DPI awareness model, which means that we
do not handle WM_DPICHANGED, unless one sets the
GDK_WIN32_PER_MONITOR_HIDPI envvar, where notes for it are in the
following point.
-Automatic scaling during WM_DISPLAYCHANGE is handled (DPI setting change of
current monitor) is now supported. WM_DPICHANGED is handled as well,
except that the window positioning during the change of scaling still
needs to be refined, a change in GDK itself may be required for this.
-I am unable to test the wintab items because I don't have such devices
around.
https://bugzilla.gnome.org/show_bug.cgi?id=768081
2016-06-27 05:16:43 +00:00
|
|
|
enum dpi_aware_status {
|
|
|
|
DPI_STATUS_PENDING,
|
|
|
|
DPI_STATUS_SUCCESS,
|
|
|
|
DPI_STATUS_DISABLED,
|
|
|
|
DPI_STATUS_FAILED
|
|
|
|
} status = DPI_STATUS_PENDING;
|
|
|
|
|
|
|
|
if (g_win32_check_windows_version (6, 3, 0, G_WIN32_OS_ANY))
|
|
|
|
{
|
|
|
|
/* If we are on Windows 8.1 or later, cache up functions from shcore.dll, by all means */
|
|
|
|
display->have_at_least_win81 = TRUE;
|
2019-12-04 10:41:05 +00:00
|
|
|
|
|
|
|
if (user32 != NULL)
|
|
|
|
{
|
|
|
|
display->user32_dpi_funcs.setPDAC =
|
|
|
|
(funcSPDAC) GetProcAddress (user32, "SetProcessDpiAwarenessContext");
|
|
|
|
display->user32_dpi_funcs.getTDAC =
|
|
|
|
(funcGTDAC) GetProcAddress (user32, "GetThreadDpiAwarenessContext");
|
|
|
|
display->user32_dpi_funcs.areDACEqual =
|
|
|
|
(funcADACE) GetProcAddress (user32, "AreDpiAwarenessContextsEqual");
|
|
|
|
}
|
|
|
|
|
GDK-Win32/4.0: Enable HiDPI support for Windows
This enables HiDPI support for GTK+ on Windows, so that the
fonts and window look better on HiDPI displays. Notes for the current
work:
-The DPI awareness enabling can be disabled if and only if an application
manifest is not embedded in the app to enable DPI awareness AND a user
compatibility setting is not set to limit DPI awareness for the app, via
the envvar GDK_WIN32_DISABLE_HIDPI. The app manifest/user setting for
DPI awareness will always win against the envvar, and so the HiDPI items
will be always setup in such scenarios, unless DPI awareness is disabled.
-Both automatic detection for the scaling factor and setting the scale
factor using the GDK_SCALE envvar are supported, where the envvar takes
precedence, which will therefore disable automatic scaling when
resolution changes.
-We now default to a per-system DPI awareness model, which means that we
do not handle WM_DPICHANGED, unless one sets the
GDK_WIN32_PER_MONITOR_HIDPI envvar, where notes for it are in the
following point.
-Automatic scaling during WM_DISPLAYCHANGE is handled (DPI setting change of
current monitor) is now supported. WM_DPICHANGED is handled as well,
except that the window positioning during the change of scaling still
needs to be refined, a change in GDK itself may be required for this.
-I am unable to test the wintab items because I don't have such devices
around.
https://bugzilla.gnome.org/show_bug.cgi?id=768081
2016-06-27 05:16:43 +00:00
|
|
|
display->shcore_funcs.hshcore = LoadLibraryW (L"shcore.dll");
|
|
|
|
|
|
|
|
if (display->shcore_funcs.hshcore != NULL)
|
|
|
|
{
|
|
|
|
display->shcore_funcs.setDpiAwareFunc =
|
|
|
|
(funcSetProcessDpiAwareness) GetProcAddress (display->shcore_funcs.hshcore,
|
|
|
|
"SetProcessDpiAwareness");
|
|
|
|
display->shcore_funcs.getDpiAwareFunc =
|
|
|
|
(funcGetProcessDpiAwareness) GetProcAddress (display->shcore_funcs.hshcore,
|
|
|
|
"GetProcessDpiAwareness");
|
|
|
|
|
|
|
|
display->shcore_funcs.getDpiForMonitorFunc =
|
|
|
|
(funcGetDpiForMonitor) GetProcAddress (display->shcore_funcs.hshcore,
|
|
|
|
"GetDpiForMonitor");
|
|
|
|
}
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
/* Windows Vista through 8: use functions from user32.dll directly */
|
|
|
|
|
|
|
|
display->have_at_least_win81 = FALSE;
|
|
|
|
|
|
|
|
if (user32 != NULL)
|
|
|
|
{
|
|
|
|
display->user32_dpi_funcs.setDpiAwareFunc =
|
|
|
|
(funcSetProcessDPIAware) GetProcAddress (user32, "SetProcessDPIAware");
|
|
|
|
display->user32_dpi_funcs.isDpiAwareFunc =
|
|
|
|
(funcIsProcessDPIAware) GetProcAddress (user32, "IsProcessDPIAware");
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (g_getenv ("GDK_WIN32_DISABLE_HIDPI") == NULL)
|
|
|
|
{
|
|
|
|
/* For Windows 8.1 and later, use SetProcessDPIAwareness() */
|
|
|
|
if (display->have_at_least_win81)
|
|
|
|
{
|
|
|
|
/* then make the GDK-using app DPI-aware */
|
2019-12-04 10:41:05 +00:00
|
|
|
if (display->user32_dpi_funcs.setPDAC != NULL)
|
|
|
|
{
|
|
|
|
HANDLE hidpi_mode_ctx;
|
|
|
|
GdkWin32ProcessDpiAwareness hidpi_mode;
|
|
|
|
|
|
|
|
/* TODO: See how per-monitor DPI awareness is done by the Wayland backend */
|
|
|
|
if (g_getenv ("GDK_WIN32_PER_MONITOR_HIDPI") != NULL)
|
|
|
|
{
|
|
|
|
hidpi_mode_ctx = DPI_AWARENESS_CONTEXT_PER_MONITOR_AWARE_V2;
|
|
|
|
hidpi_mode = PROCESS_PER_MONITOR_DPI_AWARE;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
hidpi_mode_ctx = DPI_AWARENESS_CONTEXT_SYSTEM_AWARE;
|
|
|
|
hidpi_mode = PROCESS_SYSTEM_DPI_AWARE;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (display->user32_dpi_funcs.setPDAC (hidpi_mode_ctx))
|
|
|
|
{
|
|
|
|
display->dpi_aware_type = hidpi_mode;
|
|
|
|
status = DPI_STATUS_SUCCESS;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
DWORD err = GetLastError ();
|
|
|
|
|
|
|
|
if (err == ERROR_ACCESS_DENIED)
|
|
|
|
check_for_dpi_awareness = TRUE;
|
|
|
|
else
|
|
|
|
{
|
|
|
|
display->dpi_aware_type = PROCESS_DPI_UNAWARE;
|
|
|
|
status = DPI_STATUS_FAILED;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
else if (display->shcore_funcs.setDpiAwareFunc != NULL)
|
GDK-Win32/4.0: Enable HiDPI support for Windows
This enables HiDPI support for GTK+ on Windows, so that the
fonts and window look better on HiDPI displays. Notes for the current
work:
-The DPI awareness enabling can be disabled if and only if an application
manifest is not embedded in the app to enable DPI awareness AND a user
compatibility setting is not set to limit DPI awareness for the app, via
the envvar GDK_WIN32_DISABLE_HIDPI. The app manifest/user setting for
DPI awareness will always win against the envvar, and so the HiDPI items
will be always setup in such scenarios, unless DPI awareness is disabled.
-Both automatic detection for the scaling factor and setting the scale
factor using the GDK_SCALE envvar are supported, where the envvar takes
precedence, which will therefore disable automatic scaling when
resolution changes.
-We now default to a per-system DPI awareness model, which means that we
do not handle WM_DPICHANGED, unless one sets the
GDK_WIN32_PER_MONITOR_HIDPI envvar, where notes for it are in the
following point.
-Automatic scaling during WM_DISPLAYCHANGE is handled (DPI setting change of
current monitor) is now supported. WM_DPICHANGED is handled as well,
except that the window positioning during the change of scaling still
needs to be refined, a change in GDK itself may be required for this.
-I am unable to test the wintab items because I don't have such devices
around.
https://bugzilla.gnome.org/show_bug.cgi?id=768081
2016-06-27 05:16:43 +00:00
|
|
|
{
|
|
|
|
GdkWin32ProcessDpiAwareness hidpi_mode;
|
|
|
|
|
|
|
|
/* TODO: See how per-monitor DPI awareness is done by the Wayland backend */
|
|
|
|
if (g_getenv ("GDK_WIN32_PER_MONITOR_HIDPI") != NULL)
|
|
|
|
hidpi_mode = PROCESS_PER_MONITOR_DPI_AWARE;
|
|
|
|
else
|
|
|
|
hidpi_mode = PROCESS_SYSTEM_DPI_AWARE;
|
|
|
|
|
|
|
|
switch (display->shcore_funcs.setDpiAwareFunc (hidpi_mode))
|
|
|
|
{
|
|
|
|
case S_OK:
|
|
|
|
display->dpi_aware_type = hidpi_mode;
|
|
|
|
status = DPI_STATUS_SUCCESS;
|
|
|
|
break;
|
|
|
|
case E_ACCESSDENIED:
|
|
|
|
/* This means the app used a manifest to set DPI awareness, or a
|
|
|
|
DPI compatibility setting is used.
|
|
|
|
The manifest is the trump card in this game of bridge here. The
|
|
|
|
same applies if one uses the control panel or program properties to
|
|
|
|
force system DPI awareness */
|
|
|
|
check_for_dpi_awareness = TRUE;
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
display->dpi_aware_type = PROCESS_DPI_UNAWARE;
|
|
|
|
status = DPI_STATUS_FAILED;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
2017-01-09 09:53:46 +00:00
|
|
|
else
|
GDK-Win32/4.0: Enable HiDPI support for Windows
This enables HiDPI support for GTK+ on Windows, so that the
fonts and window look better on HiDPI displays. Notes for the current
work:
-The DPI awareness enabling can be disabled if and only if an application
manifest is not embedded in the app to enable DPI awareness AND a user
compatibility setting is not set to limit DPI awareness for the app, via
the envvar GDK_WIN32_DISABLE_HIDPI. The app manifest/user setting for
DPI awareness will always win against the envvar, and so the HiDPI items
will be always setup in such scenarios, unless DPI awareness is disabled.
-Both automatic detection for the scaling factor and setting the scale
factor using the GDK_SCALE envvar are supported, where the envvar takes
precedence, which will therefore disable automatic scaling when
resolution changes.
-We now default to a per-system DPI awareness model, which means that we
do not handle WM_DPICHANGED, unless one sets the
GDK_WIN32_PER_MONITOR_HIDPI envvar, where notes for it are in the
following point.
-Automatic scaling during WM_DISPLAYCHANGE is handled (DPI setting change of
current monitor) is now supported. WM_DPICHANGED is handled as well,
except that the window positioning during the change of scaling still
needs to be refined, a change in GDK itself may be required for this.
-I am unable to test the wintab items because I don't have such devices
around.
https://bugzilla.gnome.org/show_bug.cgi?id=768081
2016-06-27 05:16:43 +00:00
|
|
|
{
|
2017-01-09 09:53:46 +00:00
|
|
|
check_for_dpi_awareness = TRUE;
|
GDK-Win32/4.0: Enable HiDPI support for Windows
This enables HiDPI support for GTK+ on Windows, so that the
fonts and window look better on HiDPI displays. Notes for the current
work:
-The DPI awareness enabling can be disabled if and only if an application
manifest is not embedded in the app to enable DPI awareness AND a user
compatibility setting is not set to limit DPI awareness for the app, via
the envvar GDK_WIN32_DISABLE_HIDPI. The app manifest/user setting for
DPI awareness will always win against the envvar, and so the HiDPI items
will be always setup in such scenarios, unless DPI awareness is disabled.
-Both automatic detection for the scaling factor and setting the scale
factor using the GDK_SCALE envvar are supported, where the envvar takes
precedence, which will therefore disable automatic scaling when
resolution changes.
-We now default to a per-system DPI awareness model, which means that we
do not handle WM_DPICHANGED, unless one sets the
GDK_WIN32_PER_MONITOR_HIDPI envvar, where notes for it are in the
following point.
-Automatic scaling during WM_DISPLAYCHANGE is handled (DPI setting change of
current monitor) is now supported. WM_DPICHANGED is handled as well,
except that the window positioning during the change of scaling still
needs to be refined, a change in GDK itself may be required for this.
-I am unable to test the wintab items because I don't have such devices
around.
https://bugzilla.gnome.org/show_bug.cgi?id=768081
2016-06-27 05:16:43 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
/* For Windows Vista through 8, use SetProcessDPIAware() */
|
|
|
|
display->have_at_least_win81 = FALSE;
|
|
|
|
if (display->user32_dpi_funcs.setDpiAwareFunc != NULL)
|
|
|
|
{
|
|
|
|
if (display->user32_dpi_funcs.setDpiAwareFunc () != 0)
|
|
|
|
{
|
|
|
|
display->dpi_aware_type = PROCESS_SYSTEM_DPI_AWARE;
|
|
|
|
status = DPI_STATUS_SUCCESS;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
check_for_dpi_awareness = TRUE;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
display->dpi_aware_type = PROCESS_DPI_UNAWARE;
|
|
|
|
status = DPI_STATUS_FAILED;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
/* if GDK_WIN32_DISABLE_HIDPI is set, check for any DPI
|
|
|
|
* awareness settings done via manifests or user settings
|
|
|
|
*/
|
|
|
|
check_for_dpi_awareness = TRUE;
|
|
|
|
have_hpi_disable_envvar = TRUE;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (check_for_dpi_awareness)
|
|
|
|
{
|
|
|
|
if (display->have_at_least_win81)
|
|
|
|
{
|
2019-12-04 10:41:05 +00:00
|
|
|
if (display->user32_dpi_funcs.getTDAC != NULL &&
|
|
|
|
display->user32_dpi_funcs.areDACEqual != NULL)
|
|
|
|
{
|
|
|
|
HANDLE dpi_aware_ctx = display->user32_dpi_funcs.getTDAC ();
|
|
|
|
if (display->user32_dpi_funcs.areDACEqual (dpi_aware_ctx,
|
|
|
|
DPI_AWARENESS_CONTEXT_UNAWARE))
|
|
|
|
/* This means the DPI awareness setting was forcefully disabled */
|
|
|
|
status = DPI_STATUS_DISABLED;
|
|
|
|
else
|
|
|
|
{
|
|
|
|
status = DPI_STATUS_SUCCESS;
|
|
|
|
if (display->user32_dpi_funcs.areDACEqual (dpi_aware_ctx,
|
|
|
|
DPI_AWARENESS_CONTEXT_SYSTEM_AWARE))
|
|
|
|
display->dpi_aware_type = PROCESS_SYSTEM_DPI_AWARE;
|
|
|
|
else
|
|
|
|
display->dpi_aware_type = PROCESS_PER_MONITOR_DPI_AWARE_V2;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
else if (display->shcore_funcs.getDpiAwareFunc != NULL)
|
GDK-Win32/4.0: Enable HiDPI support for Windows
This enables HiDPI support for GTK+ on Windows, so that the
fonts and window look better on HiDPI displays. Notes for the current
work:
-The DPI awareness enabling can be disabled if and only if an application
manifest is not embedded in the app to enable DPI awareness AND a user
compatibility setting is not set to limit DPI awareness for the app, via
the envvar GDK_WIN32_DISABLE_HIDPI. The app manifest/user setting for
DPI awareness will always win against the envvar, and so the HiDPI items
will be always setup in such scenarios, unless DPI awareness is disabled.
-Both automatic detection for the scaling factor and setting the scale
factor using the GDK_SCALE envvar are supported, where the envvar takes
precedence, which will therefore disable automatic scaling when
resolution changes.
-We now default to a per-system DPI awareness model, which means that we
do not handle WM_DPICHANGED, unless one sets the
GDK_WIN32_PER_MONITOR_HIDPI envvar, where notes for it are in the
following point.
-Automatic scaling during WM_DISPLAYCHANGE is handled (DPI setting change of
current monitor) is now supported. WM_DPICHANGED is handled as well,
except that the window positioning during the change of scaling still
needs to be refined, a change in GDK itself may be required for this.
-I am unable to test the wintab items because I don't have such devices
around.
https://bugzilla.gnome.org/show_bug.cgi?id=768081
2016-06-27 05:16:43 +00:00
|
|
|
{
|
|
|
|
display->shcore_funcs.getDpiAwareFunc (NULL, &display->dpi_aware_type);
|
|
|
|
|
|
|
|
if (display->dpi_aware_type != PROCESS_DPI_UNAWARE)
|
|
|
|
status = DPI_STATUS_SUCCESS;
|
|
|
|
else
|
|
|
|
/* This means the DPI awareness setting was forcefully disabled */
|
|
|
|
status = DPI_STATUS_DISABLED;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
display->dpi_aware_type = PROCESS_DPI_UNAWARE;
|
|
|
|
status = DPI_STATUS_FAILED;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
if (display->user32_dpi_funcs.isDpiAwareFunc != NULL)
|
|
|
|
{
|
|
|
|
/* This most probably means DPI awareness is set through
|
|
|
|
the manifest, or a DPI compatibility setting is used. */
|
|
|
|
display->dpi_aware_type = display->user32_dpi_funcs.isDpiAwareFunc () ?
|
|
|
|
PROCESS_SYSTEM_DPI_AWARE :
|
|
|
|
PROCESS_DPI_UNAWARE;
|
|
|
|
|
|
|
|
if (display->dpi_aware_type == PROCESS_SYSTEM_DPI_AWARE)
|
|
|
|
status = DPI_STATUS_SUCCESS;
|
|
|
|
else
|
|
|
|
status = DPI_STATUS_DISABLED;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
display->dpi_aware_type = PROCESS_DPI_UNAWARE;
|
|
|
|
status = DPI_STATUS_FAILED;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if (have_hpi_disable_envvar &&
|
|
|
|
status == DPI_STATUS_SUCCESS)
|
|
|
|
{
|
|
|
|
/* The user setting or application manifest trumps over GDK_WIN32_DISABLE_HIDPI */
|
|
|
|
g_print ("Note: GDK_WIN32_DISABLE_HIDPI is ignored due to preset\n"
|
|
|
|
" DPI awareness settings in user settings or application\n"
|
2019-12-04 10:41:05 +00:00
|
|
|
" manifest, DPI awareness is still enabled.\n");
|
GDK-Win32/4.0: Enable HiDPI support for Windows
This enables HiDPI support for GTK+ on Windows, so that the
fonts and window look better on HiDPI displays. Notes for the current
work:
-The DPI awareness enabling can be disabled if and only if an application
manifest is not embedded in the app to enable DPI awareness AND a user
compatibility setting is not set to limit DPI awareness for the app, via
the envvar GDK_WIN32_DISABLE_HIDPI. The app manifest/user setting for
DPI awareness will always win against the envvar, and so the HiDPI items
will be always setup in such scenarios, unless DPI awareness is disabled.
-Both automatic detection for the scaling factor and setting the scale
factor using the GDK_SCALE envvar are supported, where the envvar takes
precedence, which will therefore disable automatic scaling when
resolution changes.
-We now default to a per-system DPI awareness model, which means that we
do not handle WM_DPICHANGED, unless one sets the
GDK_WIN32_PER_MONITOR_HIDPI envvar, where notes for it are in the
following point.
-Automatic scaling during WM_DISPLAYCHANGE is handled (DPI setting change of
current monitor) is now supported. WM_DPICHANGED is handled as well,
except that the window positioning during the change of scaling still
needs to be refined, a change in GDK itself may be required for this.
-I am unable to test the wintab items because I don't have such devices
around.
https://bugzilla.gnome.org/show_bug.cgi?id=768081
2016-06-27 05:16:43 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
switch (status)
|
|
|
|
{
|
|
|
|
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"));
|
|
|
|
break;
|
|
|
|
case DPI_STATUS_DISABLED:
|
|
|
|
GDK_NOTE (MISC, g_message ("HiDPI support disabled via manifest"));
|
|
|
|
break;
|
|
|
|
case DPI_STATUS_FAILED:
|
|
|
|
g_warning ("Failed to enable HiDPI support.");
|
2018-06-10 20:57:18 +00:00
|
|
|
break;
|
|
|
|
case DPI_STATUS_PENDING:
|
|
|
|
g_assert_not_reached ();
|
|
|
|
break;
|
GDK-Win32/4.0: Enable HiDPI support for Windows
This enables HiDPI support for GTK+ on Windows, so that the
fonts and window look better on HiDPI displays. Notes for the current
work:
-The DPI awareness enabling can be disabled if and only if an application
manifest is not embedded in the app to enable DPI awareness AND a user
compatibility setting is not set to limit DPI awareness for the app, via
the envvar GDK_WIN32_DISABLE_HIDPI. The app manifest/user setting for
DPI awareness will always win against the envvar, and so the HiDPI items
will be always setup in such scenarios, unless DPI awareness is disabled.
-Both automatic detection for the scaling factor and setting the scale
factor using the GDK_SCALE envvar are supported, where the envvar takes
precedence, which will therefore disable automatic scaling when
resolution changes.
-We now default to a per-system DPI awareness model, which means that we
do not handle WM_DPICHANGED, unless one sets the
GDK_WIN32_PER_MONITOR_HIDPI envvar, where notes for it are in the
following point.
-Automatic scaling during WM_DISPLAYCHANGE is handled (DPI setting change of
current monitor) is now supported. WM_DPICHANGED is handled as well,
except that the window positioning during the change of scaling still
needs to be refined, a change in GDK itself may be required for this.
-I am unable to test the wintab items because I don't have such devices
around.
https://bugzilla.gnome.org/show_bug.cgi?id=768081
2016-06-27 05:16:43 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2022-01-05 14:44:49 +00:00
|
|
|
gboolean
|
|
|
|
_gdk_win32_check_processor (GdkWin32ProcessorCheckType check_type)
|
2019-05-07 07:09:03 +00:00
|
|
|
{
|
|
|
|
static gsize checked = 0;
|
2022-01-05 14:44:49 +00:00
|
|
|
static gboolean is_arm64 = FALSE;
|
|
|
|
static gboolean is_wow64 = FALSE;
|
2019-05-07 07:09:03 +00:00
|
|
|
|
|
|
|
if (g_once_init_enter (&checked))
|
|
|
|
{
|
2022-01-05 14:44:49 +00:00
|
|
|
gboolean fallback_wow64_check = FALSE;
|
2019-05-07 07:09:03 +00:00
|
|
|
HMODULE kernel32 = LoadLibraryW (L"kernel32.dll");
|
|
|
|
|
|
|
|
if (kernel32 != NULL)
|
|
|
|
{
|
2022-01-05 14:44:49 +00:00
|
|
|
typedef BOOL (WINAPI *funcIsWow64Process2) (HANDLE, USHORT *, USHORT *);
|
|
|
|
|
|
|
|
funcIsWow64Process2 isWow64Process2 =
|
2019-05-07 07:09:03 +00:00
|
|
|
(funcIsWow64Process2) GetProcAddress (kernel32, "IsWow64Process2");
|
|
|
|
|
2022-01-05 14:44:49 +00:00
|
|
|
if (isWow64Process2 != NULL)
|
2019-05-07 07:09:03 +00:00
|
|
|
{
|
|
|
|
USHORT proc_cpu = 0;
|
|
|
|
USHORT native_cpu = 0;
|
|
|
|
|
2022-01-05 14:44:49 +00:00
|
|
|
isWow64Process2 (GetCurrentProcess (), &proc_cpu, &native_cpu);
|
2019-05-07 07:09:03 +00:00
|
|
|
|
|
|
|
if (native_cpu == IMAGE_FILE_MACHINE_ARM64)
|
2022-01-05 14:44:49 +00:00
|
|
|
is_arm64 = TRUE;
|
|
|
|
|
|
|
|
if (proc_cpu != IMAGE_FILE_MACHINE_UNKNOWN)
|
|
|
|
is_wow64 = TRUE;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
fallback_wow64_check = TRUE;
|
2019-05-07 07:09:03 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
FreeLibrary (kernel32);
|
|
|
|
}
|
2022-01-05 14:44:49 +00:00
|
|
|
else
|
|
|
|
{
|
|
|
|
fallback_wow64_check = TRUE;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (fallback_wow64_check)
|
|
|
|
IsWow64Process (GetCurrentProcess (), &is_wow64);
|
2019-05-07 07:09:03 +00:00
|
|
|
|
|
|
|
g_once_init_leave (&checked, 1);
|
|
|
|
}
|
2022-01-05 14:44:49 +00:00
|
|
|
|
|
|
|
switch (check_type)
|
|
|
|
{
|
|
|
|
case GDK_WIN32_ARM64:
|
|
|
|
return is_arm64;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case GDK_WIN32_WOW64:
|
|
|
|
return is_wow64;
|
|
|
|
break;
|
|
|
|
|
|
|
|
default:
|
|
|
|
g_warning ("unknown CPU check type");
|
|
|
|
return FALSE;
|
|
|
|
break;
|
|
|
|
}
|
2019-05-07 07:09:03 +00:00
|
|
|
}
|
|
|
|
|
2011-01-02 10:51:25 +00:00
|
|
|
static void
|
GDK-Win32: Clean up HiDPI support and WGL a bit
Make _gdk_win32_display_get_monitor_scale_factor() less complex, by:
* Drop the preceding underscore.
* Dropping an unused parameter.
* Using a GdkSurface instead of a HWND, as the HWND that we pass into
this function might have been taken from a GdkSurface, which are now
always created with CS_OWNDC. This means if a GdkSurface was passed
in, we ensure that we only acquire the DC from the HWND once, and do
not attempt to call ReleaseDC() on it.
* Store the HDC that we acquire from the GdkSurface's HWND into the
surface, and use that as the HDC we need for our GdkGLContext.
* Drop the gl_hwnd from GdkWin32Display, as that is really should be
stored in the GdkSurface.
* For functions that were updated, name GdkWin32Display variables as
display_win32 and GdkSurface variables as surface, to unify things.
* Stop calling ReleaseDC() on the HDC that we use for OpenGL, since
they were acquired from HWND's created with CS_OWNDC.
2021-07-19 10:20:09 +00:00
|
|
|
gdk_win32_display_init (GdkWin32Display *display_win32)
|
2011-01-02 10:51:25 +00:00
|
|
|
{
|
2020-07-24 18:40:36 +00:00
|
|
|
const char *scale_str = g_getenv ("GDK_SCALE");
|
GDK-Win32/4.0: Enable HiDPI support for Windows
This enables HiDPI support for GTK+ on Windows, so that the
fonts and window look better on HiDPI displays. Notes for the current
work:
-The DPI awareness enabling can be disabled if and only if an application
manifest is not embedded in the app to enable DPI awareness AND a user
compatibility setting is not set to limit DPI awareness for the app, via
the envvar GDK_WIN32_DISABLE_HIDPI. The app manifest/user setting for
DPI awareness will always win against the envvar, and so the HiDPI items
will be always setup in such scenarios, unless DPI awareness is disabled.
-Both automatic detection for the scaling factor and setting the scale
factor using the GDK_SCALE envvar are supported, where the envvar takes
precedence, which will therefore disable automatic scaling when
resolution changes.
-We now default to a per-system DPI awareness model, which means that we
do not handle WM_DPICHANGED, unless one sets the
GDK_WIN32_PER_MONITOR_HIDPI envvar, where notes for it are in the
following point.
-Automatic scaling during WM_DISPLAYCHANGE is handled (DPI setting change of
current monitor) is now supported. WM_DPICHANGED is handled as well,
except that the window positioning during the change of scaling still
needs to be refined, a change in GDK itself may be required for this.
-I am unable to test the wintab items because I don't have such devices
around.
https://bugzilla.gnome.org/show_bug.cgi?id=768081
2016-06-27 05:16:43 +00:00
|
|
|
|
GDK-Win32: Clean up HiDPI support and WGL a bit
Make _gdk_win32_display_get_monitor_scale_factor() less complex, by:
* Drop the preceding underscore.
* Dropping an unused parameter.
* Using a GdkSurface instead of a HWND, as the HWND that we pass into
this function might have been taken from a GdkSurface, which are now
always created with CS_OWNDC. This means if a GdkSurface was passed
in, we ensure that we only acquire the DC from the HWND once, and do
not attempt to call ReleaseDC() on it.
* Store the HDC that we acquire from the GdkSurface's HWND into the
surface, and use that as the HDC we need for our GdkGLContext.
* Drop the gl_hwnd from GdkWin32Display, as that is really should be
stored in the GdkSurface.
* For functions that were updated, name GdkWin32Display variables as
display_win32 and GdkSurface variables as surface, to unify things.
* Stop calling ReleaseDC() on the HDC that we use for OpenGL, since
they were acquired from HWND's created with CS_OWNDC.
2021-07-19 10:20:09 +00:00
|
|
|
display_win32->monitors = G_LIST_MODEL (g_list_store_new (GDK_TYPE_MONITOR));
|
GDK-Win32/4.0: Enable HiDPI support for Windows
This enables HiDPI support for GTK+ on Windows, so that the
fonts and window look better on HiDPI displays. Notes for the current
work:
-The DPI awareness enabling can be disabled if and only if an application
manifest is not embedded in the app to enable DPI awareness AND a user
compatibility setting is not set to limit DPI awareness for the app, via
the envvar GDK_WIN32_DISABLE_HIDPI. The app manifest/user setting for
DPI awareness will always win against the envvar, and so the HiDPI items
will be always setup in such scenarios, unless DPI awareness is disabled.
-Both automatic detection for the scaling factor and setting the scale
factor using the GDK_SCALE envvar are supported, where the envvar takes
precedence, which will therefore disable automatic scaling when
resolution changes.
-We now default to a per-system DPI awareness model, which means that we
do not handle WM_DPICHANGED, unless one sets the
GDK_WIN32_PER_MONITOR_HIDPI envvar, where notes for it are in the
following point.
-Automatic scaling during WM_DISPLAYCHANGE is handled (DPI setting change of
current monitor) is now supported. WM_DPICHANGED is handled as well,
except that the window positioning during the change of scaling still
needs to be refined, a change in GDK itself may be required for this.
-I am unable to test the wintab items because I don't have such devices
around.
https://bugzilla.gnome.org/show_bug.cgi?id=768081
2016-06-27 05:16:43 +00:00
|
|
|
|
GDK-Win32: Clean up HiDPI support and WGL a bit
Make _gdk_win32_display_get_monitor_scale_factor() less complex, by:
* Drop the preceding underscore.
* Dropping an unused parameter.
* Using a GdkSurface instead of a HWND, as the HWND that we pass into
this function might have been taken from a GdkSurface, which are now
always created with CS_OWNDC. This means if a GdkSurface was passed
in, we ensure that we only acquire the DC from the HWND once, and do
not attempt to call ReleaseDC() on it.
* Store the HDC that we acquire from the GdkSurface's HWND into the
surface, and use that as the HDC we need for our GdkGLContext.
* Drop the gl_hwnd from GdkWin32Display, as that is really should be
stored in the GdkSurface.
* For functions that were updated, name GdkWin32Display variables as
display_win32 and GdkSurface variables as surface, to unify things.
* Stop calling ReleaseDC() on the HDC that we use for OpenGL, since
they were acquired from HWND's created with CS_OWNDC.
2021-07-19 10:20:09 +00:00
|
|
|
_gdk_win32_enable_hidpi (display_win32);
|
2022-01-05 14:44:49 +00:00
|
|
|
display_win32->running_on_arm64 = _gdk_win32_check_processor (GDK_WIN32_ARM64);
|
GDK-Win32/4.0: Enable HiDPI support for Windows
This enables HiDPI support for GTK+ on Windows, so that the
fonts and window look better on HiDPI displays. Notes for the current
work:
-The DPI awareness enabling can be disabled if and only if an application
manifest is not embedded in the app to enable DPI awareness AND a user
compatibility setting is not set to limit DPI awareness for the app, via
the envvar GDK_WIN32_DISABLE_HIDPI. The app manifest/user setting for
DPI awareness will always win against the envvar, and so the HiDPI items
will be always setup in such scenarios, unless DPI awareness is disabled.
-Both automatic detection for the scaling factor and setting the scale
factor using the GDK_SCALE envvar are supported, where the envvar takes
precedence, which will therefore disable automatic scaling when
resolution changes.
-We now default to a per-system DPI awareness model, which means that we
do not handle WM_DPICHANGED, unless one sets the
GDK_WIN32_PER_MONITOR_HIDPI envvar, where notes for it are in the
following point.
-Automatic scaling during WM_DISPLAYCHANGE is handled (DPI setting change of
current monitor) is now supported. WM_DPICHANGED is handled as well,
except that the window positioning during the change of scaling still
needs to be refined, a change in GDK itself may be required for this.
-I am unable to test the wintab items because I don't have such devices
around.
https://bugzilla.gnome.org/show_bug.cgi?id=768081
2016-06-27 05:16:43 +00:00
|
|
|
|
|
|
|
/* if we have DPI awareness, set up fixed scale if set */
|
GDK-Win32: Clean up HiDPI support and WGL a bit
Make _gdk_win32_display_get_monitor_scale_factor() less complex, by:
* Drop the preceding underscore.
* Dropping an unused parameter.
* Using a GdkSurface instead of a HWND, as the HWND that we pass into
this function might have been taken from a GdkSurface, which are now
always created with CS_OWNDC. This means if a GdkSurface was passed
in, we ensure that we only acquire the DC from the HWND once, and do
not attempt to call ReleaseDC() on it.
* Store the HDC that we acquire from the GdkSurface's HWND into the
surface, and use that as the HDC we need for our GdkGLContext.
* Drop the gl_hwnd from GdkWin32Display, as that is really should be
stored in the GdkSurface.
* For functions that were updated, name GdkWin32Display variables as
display_win32 and GdkSurface variables as surface, to unify things.
* Stop calling ReleaseDC() on the HDC that we use for OpenGL, since
they were acquired from HWND's created with CS_OWNDC.
2021-07-19 10:20:09 +00:00
|
|
|
if (display_win32->dpi_aware_type != PROCESS_DPI_UNAWARE &&
|
GDK-Win32/4.0: Enable HiDPI support for Windows
This enables HiDPI support for GTK+ on Windows, so that the
fonts and window look better on HiDPI displays. Notes for the current
work:
-The DPI awareness enabling can be disabled if and only if an application
manifest is not embedded in the app to enable DPI awareness AND a user
compatibility setting is not set to limit DPI awareness for the app, via
the envvar GDK_WIN32_DISABLE_HIDPI. The app manifest/user setting for
DPI awareness will always win against the envvar, and so the HiDPI items
will be always setup in such scenarios, unless DPI awareness is disabled.
-Both automatic detection for the scaling factor and setting the scale
factor using the GDK_SCALE envvar are supported, where the envvar takes
precedence, which will therefore disable automatic scaling when
resolution changes.
-We now default to a per-system DPI awareness model, which means that we
do not handle WM_DPICHANGED, unless one sets the
GDK_WIN32_PER_MONITOR_HIDPI envvar, where notes for it are in the
following point.
-Automatic scaling during WM_DISPLAYCHANGE is handled (DPI setting change of
current monitor) is now supported. WM_DPICHANGED is handled as well,
except that the window positioning during the change of scaling still
needs to be refined, a change in GDK itself may be required for this.
-I am unable to test the wintab items because I don't have such devices
around.
https://bugzilla.gnome.org/show_bug.cgi?id=768081
2016-06-27 05:16:43 +00:00
|
|
|
scale_str != NULL)
|
|
|
|
{
|
GDK-Win32: Clean up HiDPI support and WGL a bit
Make _gdk_win32_display_get_monitor_scale_factor() less complex, by:
* Drop the preceding underscore.
* Dropping an unused parameter.
* Using a GdkSurface instead of a HWND, as the HWND that we pass into
this function might have been taken from a GdkSurface, which are now
always created with CS_OWNDC. This means if a GdkSurface was passed
in, we ensure that we only acquire the DC from the HWND once, and do
not attempt to call ReleaseDC() on it.
* Store the HDC that we acquire from the GdkSurface's HWND into the
surface, and use that as the HDC we need for our GdkGLContext.
* Drop the gl_hwnd from GdkWin32Display, as that is really should be
stored in the GdkSurface.
* For functions that were updated, name GdkWin32Display variables as
display_win32 and GdkSurface variables as surface, to unify things.
* Stop calling ReleaseDC() on the HDC that we use for OpenGL, since
they were acquired from HWND's created with CS_OWNDC.
2021-07-19 10:20:09 +00:00
|
|
|
display_win32->surface_scale = atol (scale_str);
|
GDK-Win32/4.0: Enable HiDPI support for Windows
This enables HiDPI support for GTK+ on Windows, so that the
fonts and window look better on HiDPI displays. Notes for the current
work:
-The DPI awareness enabling can be disabled if and only if an application
manifest is not embedded in the app to enable DPI awareness AND a user
compatibility setting is not set to limit DPI awareness for the app, via
the envvar GDK_WIN32_DISABLE_HIDPI. The app manifest/user setting for
DPI awareness will always win against the envvar, and so the HiDPI items
will be always setup in such scenarios, unless DPI awareness is disabled.
-Both automatic detection for the scaling factor and setting the scale
factor using the GDK_SCALE envvar are supported, where the envvar takes
precedence, which will therefore disable automatic scaling when
resolution changes.
-We now default to a per-system DPI awareness model, which means that we
do not handle WM_DPICHANGED, unless one sets the
GDK_WIN32_PER_MONITOR_HIDPI envvar, where notes for it are in the
following point.
-Automatic scaling during WM_DISPLAYCHANGE is handled (DPI setting change of
current monitor) is now supported. WM_DPICHANGED is handled as well,
except that the window positioning during the change of scaling still
needs to be refined, a change in GDK itself may be required for this.
-I am unable to test the wintab items because I don't have such devices
around.
https://bugzilla.gnome.org/show_bug.cgi?id=768081
2016-06-27 05:16:43 +00:00
|
|
|
|
GDK-Win32: Clean up HiDPI support and WGL a bit
Make _gdk_win32_display_get_monitor_scale_factor() less complex, by:
* Drop the preceding underscore.
* Dropping an unused parameter.
* Using a GdkSurface instead of a HWND, as the HWND that we pass into
this function might have been taken from a GdkSurface, which are now
always created with CS_OWNDC. This means if a GdkSurface was passed
in, we ensure that we only acquire the DC from the HWND once, and do
not attempt to call ReleaseDC() on it.
* Store the HDC that we acquire from the GdkSurface's HWND into the
surface, and use that as the HDC we need for our GdkGLContext.
* Drop the gl_hwnd from GdkWin32Display, as that is really should be
stored in the GdkSurface.
* For functions that were updated, name GdkWin32Display variables as
display_win32 and GdkSurface variables as surface, to unify things.
* Stop calling ReleaseDC() on the HDC that we use for OpenGL, since
they were acquired from HWND's created with CS_OWNDC.
2021-07-19 10:20:09 +00:00
|
|
|
if (display_win32->surface_scale <= 0)
|
|
|
|
display_win32->surface_scale = 1;
|
GDK-Win32/4.0: Enable HiDPI support for Windows
This enables HiDPI support for GTK+ on Windows, so that the
fonts and window look better on HiDPI displays. Notes for the current
work:
-The DPI awareness enabling can be disabled if and only if an application
manifest is not embedded in the app to enable DPI awareness AND a user
compatibility setting is not set to limit DPI awareness for the app, via
the envvar GDK_WIN32_DISABLE_HIDPI. The app manifest/user setting for
DPI awareness will always win against the envvar, and so the HiDPI items
will be always setup in such scenarios, unless DPI awareness is disabled.
-Both automatic detection for the scaling factor and setting the scale
factor using the GDK_SCALE envvar are supported, where the envvar takes
precedence, which will therefore disable automatic scaling when
resolution changes.
-We now default to a per-system DPI awareness model, which means that we
do not handle WM_DPICHANGED, unless one sets the
GDK_WIN32_PER_MONITOR_HIDPI envvar, where notes for it are in the
following point.
-Automatic scaling during WM_DISPLAYCHANGE is handled (DPI setting change of
current monitor) is now supported. WM_DPICHANGED is handled as well,
except that the window positioning during the change of scaling still
needs to be refined, a change in GDK itself may be required for this.
-I am unable to test the wintab items because I don't have such devices
around.
https://bugzilla.gnome.org/show_bug.cgi?id=768081
2016-06-27 05:16:43 +00:00
|
|
|
|
GDK-Win32: Clean up HiDPI support and WGL a bit
Make _gdk_win32_display_get_monitor_scale_factor() less complex, by:
* Drop the preceding underscore.
* Dropping an unused parameter.
* Using a GdkSurface instead of a HWND, as the HWND that we pass into
this function might have been taken from a GdkSurface, which are now
always created with CS_OWNDC. This means if a GdkSurface was passed
in, we ensure that we only acquire the DC from the HWND once, and do
not attempt to call ReleaseDC() on it.
* Store the HDC that we acquire from the GdkSurface's HWND into the
surface, and use that as the HDC we need for our GdkGLContext.
* Drop the gl_hwnd from GdkWin32Display, as that is really should be
stored in the GdkSurface.
* For functions that were updated, name GdkWin32Display variables as
display_win32 and GdkSurface variables as surface, to unify things.
* Stop calling ReleaseDC() on the HDC that we use for OpenGL, since
they were acquired from HWND's created with CS_OWNDC.
2021-07-19 10:20:09 +00:00
|
|
|
display_win32->has_fixed_scale = TRUE;
|
GDK-Win32/4.0: Enable HiDPI support for Windows
This enables HiDPI support for GTK+ on Windows, so that the
fonts and window look better on HiDPI displays. Notes for the current
work:
-The DPI awareness enabling can be disabled if and only if an application
manifest is not embedded in the app to enable DPI awareness AND a user
compatibility setting is not set to limit DPI awareness for the app, via
the envvar GDK_WIN32_DISABLE_HIDPI. The app manifest/user setting for
DPI awareness will always win against the envvar, and so the HiDPI items
will be always setup in such scenarios, unless DPI awareness is disabled.
-Both automatic detection for the scaling factor and setting the scale
factor using the GDK_SCALE envvar are supported, where the envvar takes
precedence, which will therefore disable automatic scaling when
resolution changes.
-We now default to a per-system DPI awareness model, which means that we
do not handle WM_DPICHANGED, unless one sets the
GDK_WIN32_PER_MONITOR_HIDPI envvar, where notes for it are in the
following point.
-Automatic scaling during WM_DISPLAYCHANGE is handled (DPI setting change of
current monitor) is now supported. WM_DPICHANGED is handled as well,
except that the window positioning during the change of scaling still
needs to be refined, a change in GDK itself may be required for this.
-I am unable to test the wintab items because I don't have such devices
around.
https://bugzilla.gnome.org/show_bug.cgi?id=768081
2016-06-27 05:16:43 +00:00
|
|
|
}
|
|
|
|
else
|
GDK-Win32: Clean up HiDPI support and WGL a bit
Make _gdk_win32_display_get_monitor_scale_factor() less complex, by:
* Drop the preceding underscore.
* Dropping an unused parameter.
* Using a GdkSurface instead of a HWND, as the HWND that we pass into
this function might have been taken from a GdkSurface, which are now
always created with CS_OWNDC. This means if a GdkSurface was passed
in, we ensure that we only acquire the DC from the HWND once, and do
not attempt to call ReleaseDC() on it.
* Store the HDC that we acquire from the GdkSurface's HWND into the
surface, and use that as the HDC we need for our GdkGLContext.
* Drop the gl_hwnd from GdkWin32Display, as that is really should be
stored in the GdkSurface.
* For functions that were updated, name GdkWin32Display variables as
display_win32 and GdkSurface variables as surface, to unify things.
* Stop calling ReleaseDC() on the HDC that we use for OpenGL, since
they were acquired from HWND's created with CS_OWNDC.
2021-07-19 10:20:09 +00:00
|
|
|
display_win32->surface_scale =
|
|
|
|
gdk_win32_display_get_monitor_scale_factor (display_win32, NULL, NULL);
|
GDK-Win32/4.0: Enable HiDPI support for Windows
This enables HiDPI support for GTK+ on Windows, so that the
fonts and window look better on HiDPI displays. Notes for the current
work:
-The DPI awareness enabling can be disabled if and only if an application
manifest is not embedded in the app to enable DPI awareness AND a user
compatibility setting is not set to limit DPI awareness for the app, via
the envvar GDK_WIN32_DISABLE_HIDPI. The app manifest/user setting for
DPI awareness will always win against the envvar, and so the HiDPI items
will be always setup in such scenarios, unless DPI awareness is disabled.
-Both automatic detection for the scaling factor and setting the scale
factor using the GDK_SCALE envvar are supported, where the envvar takes
precedence, which will therefore disable automatic scaling when
resolution changes.
-We now default to a per-system DPI awareness model, which means that we
do not handle WM_DPICHANGED, unless one sets the
GDK_WIN32_PER_MONITOR_HIDPI envvar, where notes for it are in the
following point.
-Automatic scaling during WM_DISPLAYCHANGE is handled (DPI setting change of
current monitor) is now supported. WM_DPICHANGED is handled as well,
except that the window positioning during the change of scaling still
needs to be refined, a change in GDK itself may be required for this.
-I am unable to test the wintab items because I don't have such devices
around.
https://bugzilla.gnome.org/show_bug.cgi?id=768081
2016-06-27 05:16:43 +00:00
|
|
|
|
GDK-Win32: Clean up HiDPI support and WGL a bit
Make _gdk_win32_display_get_monitor_scale_factor() less complex, by:
* Drop the preceding underscore.
* Dropping an unused parameter.
* Using a GdkSurface instead of a HWND, as the HWND that we pass into
this function might have been taken from a GdkSurface, which are now
always created with CS_OWNDC. This means if a GdkSurface was passed
in, we ensure that we only acquire the DC from the HWND once, and do
not attempt to call ReleaseDC() on it.
* Store the HDC that we acquire from the GdkSurface's HWND into the
surface, and use that as the HDC we need for our GdkGLContext.
* Drop the gl_hwnd from GdkWin32Display, as that is really should be
stored in the GdkSurface.
* For functions that were updated, name GdkWin32Display variables as
display_win32 and GdkSurface variables as surface, to unify things.
* Stop calling ReleaseDC() on the HDC that we use for OpenGL, since
they were acquired from HWND's created with CS_OWNDC.
2021-07-19 10:20:09 +00:00
|
|
|
_gdk_win32_display_init_cursors (display_win32);
|
|
|
|
gdk_win32_display_check_composited (display_win32);
|
2016-10-29 02:37:20 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void
|
|
|
|
gdk_win32_display_check_composited (GdkWin32Display *display)
|
|
|
|
{
|
|
|
|
gboolean composited;
|
|
|
|
|
|
|
|
/* On Windows 8 and later, DWM (composition) is always enabled */
|
|
|
|
if (g_win32_check_windows_version (6, 2, 0, G_WIN32_OS_ANY))
|
|
|
|
{
|
|
|
|
composited = TRUE;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
if (DwmIsCompositionEnabled (&composited) != S_OK)
|
|
|
|
composited = FALSE;
|
|
|
|
}
|
|
|
|
|
|
|
|
gdk_display_set_composited (GDK_DISPLAY (display), composited);
|
2011-01-02 10:51:25 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
gdk_win32_display_notify_startup_complete (GdkDisplay *display,
|
2020-07-24 18:40:36 +00:00
|
|
|
const char *startup_id)
|
2011-01-02 10:51:25 +00:00
|
|
|
{
|
|
|
|
/* nothing */
|
|
|
|
}
|
2016-04-11 20:22:23 +00:00
|
|
|
|
2020-01-30 20:01:24 +00:00
|
|
|
GdkMonitor *
|
2016-04-20 07:36:00 +00:00
|
|
|
gdk_win32_display_get_primary_monitor (GdkDisplay *display)
|
|
|
|
{
|
2020-05-17 03:58:20 +00:00
|
|
|
GdkWin32Display *self = GDK_WIN32_DISPLAY (display);
|
|
|
|
GdkMonitor *result;
|
|
|
|
|
|
|
|
/* We arrange for the first monitor in the array to also be the primary monitor */
|
|
|
|
result = g_list_model_get_item (self->monitors, 0);
|
|
|
|
g_object_unref (result);
|
|
|
|
|
|
|
|
return result;
|
2016-04-20 07:36:00 +00:00
|
|
|
}
|
|
|
|
|
2020-05-13 05:00:35 +00:00
|
|
|
static GListModel *
|
|
|
|
gdk_win32_display_get_monitors (GdkDisplay *display)
|
|
|
|
{
|
|
|
|
GdkWin32Display *self = GDK_WIN32_DISPLAY (display);
|
|
|
|
|
|
|
|
return self->monitors;
|
|
|
|
}
|
|
|
|
|
GDK-Win32/4.0: Enable HiDPI support for Windows
This enables HiDPI support for GTK+ on Windows, so that the
fonts and window look better on HiDPI displays. Notes for the current
work:
-The DPI awareness enabling can be disabled if and only if an application
manifest is not embedded in the app to enable DPI awareness AND a user
compatibility setting is not set to limit DPI awareness for the app, via
the envvar GDK_WIN32_DISABLE_HIDPI. The app manifest/user setting for
DPI awareness will always win against the envvar, and so the HiDPI items
will be always setup in such scenarios, unless DPI awareness is disabled.
-Both automatic detection for the scaling factor and setting the scale
factor using the GDK_SCALE envvar are supported, where the envvar takes
precedence, which will therefore disable automatic scaling when
resolution changes.
-We now default to a per-system DPI awareness model, which means that we
do not handle WM_DPICHANGED, unless one sets the
GDK_WIN32_PER_MONITOR_HIDPI envvar, where notes for it are in the
following point.
-Automatic scaling during WM_DISPLAYCHANGE is handled (DPI setting change of
current monitor) is now supported. WM_DPICHANGED is handled as well,
except that the window positioning during the change of scaling still
needs to be refined, a change in GDK itself may be required for this.
-I am unable to test the wintab items because I don't have such devices
around.
https://bugzilla.gnome.org/show_bug.cgi?id=768081
2016-06-27 05:16:43 +00:00
|
|
|
guint
|
GDK-Win32: Clean up HiDPI support and WGL a bit
Make _gdk_win32_display_get_monitor_scale_factor() less complex, by:
* Drop the preceding underscore.
* Dropping an unused parameter.
* Using a GdkSurface instead of a HWND, as the HWND that we pass into
this function might have been taken from a GdkSurface, which are now
always created with CS_OWNDC. This means if a GdkSurface was passed
in, we ensure that we only acquire the DC from the HWND once, and do
not attempt to call ReleaseDC() on it.
* Store the HDC that we acquire from the GdkSurface's HWND into the
surface, and use that as the HDC we need for our GdkGLContext.
* Drop the gl_hwnd from GdkWin32Display, as that is really should be
stored in the GdkSurface.
* For functions that were updated, name GdkWin32Display variables as
display_win32 and GdkSurface variables as surface, to unify things.
* Stop calling ReleaseDC() on the HDC that we use for OpenGL, since
they were acquired from HWND's created with CS_OWNDC.
2021-07-19 10:20:09 +00:00
|
|
|
gdk_win32_display_get_monitor_scale_factor (GdkWin32Display *display_win32,
|
|
|
|
GdkSurface *surface,
|
|
|
|
HMONITOR hmonitor)
|
GDK-Win32/4.0: Enable HiDPI support for Windows
This enables HiDPI support for GTK+ on Windows, so that the
fonts and window look better on HiDPI displays. Notes for the current
work:
-The DPI awareness enabling can be disabled if and only if an application
manifest is not embedded in the app to enable DPI awareness AND a user
compatibility setting is not set to limit DPI awareness for the app, via
the envvar GDK_WIN32_DISABLE_HIDPI. The app manifest/user setting for
DPI awareness will always win against the envvar, and so the HiDPI items
will be always setup in such scenarios, unless DPI awareness is disabled.
-Both automatic detection for the scaling factor and setting the scale
factor using the GDK_SCALE envvar are supported, where the envvar takes
precedence, which will therefore disable automatic scaling when
resolution changes.
-We now default to a per-system DPI awareness model, which means that we
do not handle WM_DPICHANGED, unless one sets the
GDK_WIN32_PER_MONITOR_HIDPI envvar, where notes for it are in the
following point.
-Automatic scaling during WM_DISPLAYCHANGE is handled (DPI setting change of
current monitor) is now supported. WM_DPICHANGED is handled as well,
except that the window positioning during the change of scaling still
needs to be refined, a change in GDK itself may be required for this.
-I am unable to test the wintab items because I don't have such devices
around.
https://bugzilla.gnome.org/show_bug.cgi?id=768081
2016-06-27 05:16:43 +00:00
|
|
|
{
|
|
|
|
gboolean is_scale_acquired = FALSE;
|
|
|
|
gboolean use_dpi_for_monitor = FALSE;
|
|
|
|
guint dpix, dpiy;
|
|
|
|
|
GDK-Win32: Clean up HiDPI support and WGL a bit
Make _gdk_win32_display_get_monitor_scale_factor() less complex, by:
* Drop the preceding underscore.
* Dropping an unused parameter.
* Using a GdkSurface instead of a HWND, as the HWND that we pass into
this function might have been taken from a GdkSurface, which are now
always created with CS_OWNDC. This means if a GdkSurface was passed
in, we ensure that we only acquire the DC from the HWND once, and do
not attempt to call ReleaseDC() on it.
* Store the HDC that we acquire from the GdkSurface's HWND into the
surface, and use that as the HDC we need for our GdkGLContext.
* Drop the gl_hwnd from GdkWin32Display, as that is really should be
stored in the GdkSurface.
* For functions that were updated, name GdkWin32Display variables as
display_win32 and GdkSurface variables as surface, to unify things.
* Stop calling ReleaseDC() on the HDC that we use for OpenGL, since
they were acquired from HWND's created with CS_OWNDC.
2021-07-19 10:20:09 +00:00
|
|
|
if (display_win32->have_at_least_win81)
|
GDK-Win32/4.0: Enable HiDPI support for Windows
This enables HiDPI support for GTK+ on Windows, so that the
fonts and window look better on HiDPI displays. Notes for the current
work:
-The DPI awareness enabling can be disabled if and only if an application
manifest is not embedded in the app to enable DPI awareness AND a user
compatibility setting is not set to limit DPI awareness for the app, via
the envvar GDK_WIN32_DISABLE_HIDPI. The app manifest/user setting for
DPI awareness will always win against the envvar, and so the HiDPI items
will be always setup in such scenarios, unless DPI awareness is disabled.
-Both automatic detection for the scaling factor and setting the scale
factor using the GDK_SCALE envvar are supported, where the envvar takes
precedence, which will therefore disable automatic scaling when
resolution changes.
-We now default to a per-system DPI awareness model, which means that we
do not handle WM_DPICHANGED, unless one sets the
GDK_WIN32_PER_MONITOR_HIDPI envvar, where notes for it are in the
following point.
-Automatic scaling during WM_DISPLAYCHANGE is handled (DPI setting change of
current monitor) is now supported. WM_DPICHANGED is handled as well,
except that the window positioning during the change of scaling still
needs to be refined, a change in GDK itself may be required for this.
-I am unable to test the wintab items because I don't have such devices
around.
https://bugzilla.gnome.org/show_bug.cgi?id=768081
2016-06-27 05:16:43 +00:00
|
|
|
{
|
GDK-Win32: Clean up HiDPI support and WGL a bit
Make _gdk_win32_display_get_monitor_scale_factor() less complex, by:
* Drop the preceding underscore.
* Dropping an unused parameter.
* Using a GdkSurface instead of a HWND, as the HWND that we pass into
this function might have been taken from a GdkSurface, which are now
always created with CS_OWNDC. This means if a GdkSurface was passed
in, we ensure that we only acquire the DC from the HWND once, and do
not attempt to call ReleaseDC() on it.
* Store the HDC that we acquire from the GdkSurface's HWND into the
surface, and use that as the HDC we need for our GdkGLContext.
* Drop the gl_hwnd from GdkWin32Display, as that is really should be
stored in the GdkSurface.
* For functions that were updated, name GdkWin32Display variables as
display_win32 and GdkSurface variables as surface, to unify things.
* Stop calling ReleaseDC() on the HDC that we use for OpenGL, since
they were acquired from HWND's created with CS_OWNDC.
2021-07-19 10:20:09 +00:00
|
|
|
if (surface != NULL && hmonitor == NULL)
|
|
|
|
hmonitor = MonitorFromWindow (GDK_SURFACE_HWND (surface),
|
|
|
|
MONITOR_DEFAULTTONEAREST);
|
|
|
|
if (hmonitor != NULL &&
|
|
|
|
display_win32->shcore_funcs.hshcore != NULL &&
|
|
|
|
display_win32->shcore_funcs.getDpiForMonitorFunc != NULL)
|
GDK-Win32/4.0: Enable HiDPI support for Windows
This enables HiDPI support for GTK+ on Windows, so that the
fonts and window look better on HiDPI displays. Notes for the current
work:
-The DPI awareness enabling can be disabled if and only if an application
manifest is not embedded in the app to enable DPI awareness AND a user
compatibility setting is not set to limit DPI awareness for the app, via
the envvar GDK_WIN32_DISABLE_HIDPI. The app manifest/user setting for
DPI awareness will always win against the envvar, and so the HiDPI items
will be always setup in such scenarios, unless DPI awareness is disabled.
-Both automatic detection for the scaling factor and setting the scale
factor using the GDK_SCALE envvar are supported, where the envvar takes
precedence, which will therefore disable automatic scaling when
resolution changes.
-We now default to a per-system DPI awareness model, which means that we
do not handle WM_DPICHANGED, unless one sets the
GDK_WIN32_PER_MONITOR_HIDPI envvar, where notes for it are in the
following point.
-Automatic scaling during WM_DISPLAYCHANGE is handled (DPI setting change of
current monitor) is now supported. WM_DPICHANGED is handled as well,
except that the window positioning during the change of scaling still
needs to be refined, a change in GDK itself may be required for this.
-I am unable to test the wintab items because I don't have such devices
around.
https://bugzilla.gnome.org/show_bug.cgi?id=768081
2016-06-27 05:16:43 +00:00
|
|
|
use_dpi_for_monitor = TRUE;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (use_dpi_for_monitor)
|
|
|
|
{
|
|
|
|
/* Use GetDpiForMonitor() for Windows 8.1+, when we have a HMONITOR */
|
GDK-Win32: Clean up HiDPI support and WGL a bit
Make _gdk_win32_display_get_monitor_scale_factor() less complex, by:
* Drop the preceding underscore.
* Dropping an unused parameter.
* Using a GdkSurface instead of a HWND, as the HWND that we pass into
this function might have been taken from a GdkSurface, which are now
always created with CS_OWNDC. This means if a GdkSurface was passed
in, we ensure that we only acquire the DC from the HWND once, and do
not attempt to call ReleaseDC() on it.
* Store the HDC that we acquire from the GdkSurface's HWND into the
surface, and use that as the HDC we need for our GdkGLContext.
* Drop the gl_hwnd from GdkWin32Display, as that is really should be
stored in the GdkSurface.
* For functions that were updated, name GdkWin32Display variables as
display_win32 and GdkSurface variables as surface, to unify things.
* Stop calling ReleaseDC() on the HDC that we use for OpenGL, since
they were acquired from HWND's created with CS_OWNDC.
2021-07-19 10:20:09 +00:00
|
|
|
if (display_win32->shcore_funcs.getDpiForMonitorFunc (hmonitor,
|
|
|
|
MDT_EFFECTIVE_DPI,
|
|
|
|
&dpix,
|
|
|
|
&dpiy) == S_OK)
|
|
|
|
is_scale_acquired = TRUE;
|
GDK-Win32/4.0: Enable HiDPI support for Windows
This enables HiDPI support for GTK+ on Windows, so that the
fonts and window look better on HiDPI displays. Notes for the current
work:
-The DPI awareness enabling can be disabled if and only if an application
manifest is not embedded in the app to enable DPI awareness AND a user
compatibility setting is not set to limit DPI awareness for the app, via
the envvar GDK_WIN32_DISABLE_HIDPI. The app manifest/user setting for
DPI awareness will always win against the envvar, and so the HiDPI items
will be always setup in such scenarios, unless DPI awareness is disabled.
-Both automatic detection for the scaling factor and setting the scale
factor using the GDK_SCALE envvar are supported, where the envvar takes
precedence, which will therefore disable automatic scaling when
resolution changes.
-We now default to a per-system DPI awareness model, which means that we
do not handle WM_DPICHANGED, unless one sets the
GDK_WIN32_PER_MONITOR_HIDPI envvar, where notes for it are in the
following point.
-Automatic scaling during WM_DISPLAYCHANGE is handled (DPI setting change of
current monitor) is now supported. WM_DPICHANGED is handled as well,
except that the window positioning during the change of scaling still
needs to be refined, a change in GDK itself may be required for this.
-I am unable to test the wintab items because I don't have such devices
around.
https://bugzilla.gnome.org/show_bug.cgi?id=768081
2016-06-27 05:16:43 +00:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
2020-08-21 12:41:13 +00:00
|
|
|
/* Go back to GetDeviceCaps() for Windows 8 and earlier, or when we don't
|
GDK-Win32/4.0: Enable HiDPI support for Windows
This enables HiDPI support for GTK+ on Windows, so that the
fonts and window look better on HiDPI displays. Notes for the current
work:
-The DPI awareness enabling can be disabled if and only if an application
manifest is not embedded in the app to enable DPI awareness AND a user
compatibility setting is not set to limit DPI awareness for the app, via
the envvar GDK_WIN32_DISABLE_HIDPI. The app manifest/user setting for
DPI awareness will always win against the envvar, and so the HiDPI items
will be always setup in such scenarios, unless DPI awareness is disabled.
-Both automatic detection for the scaling factor and setting the scale
factor using the GDK_SCALE envvar are supported, where the envvar takes
precedence, which will therefore disable automatic scaling when
resolution changes.
-We now default to a per-system DPI awareness model, which means that we
do not handle WM_DPICHANGED, unless one sets the
GDK_WIN32_PER_MONITOR_HIDPI envvar, where notes for it are in the
following point.
-Automatic scaling during WM_DISPLAYCHANGE is handled (DPI setting change of
current monitor) is now supported. WM_DPICHANGED is handled as well,
except that the window positioning during the change of scaling still
needs to be refined, a change in GDK itself may be required for this.
-I am unable to test the wintab items because I don't have such devices
around.
https://bugzilla.gnome.org/show_bug.cgi?id=768081
2016-06-27 05:16:43 +00:00
|
|
|
* have a HMONITOR nor a HWND
|
|
|
|
*/
|
GDK-Win32: Clean up HiDPI support and WGL a bit
Make _gdk_win32_display_get_monitor_scale_factor() less complex, by:
* Drop the preceding underscore.
* Dropping an unused parameter.
* Using a GdkSurface instead of a HWND, as the HWND that we pass into
this function might have been taken from a GdkSurface, which are now
always created with CS_OWNDC. This means if a GdkSurface was passed
in, we ensure that we only acquire the DC from the HWND once, and do
not attempt to call ReleaseDC() on it.
* Store the HDC that we acquire from the GdkSurface's HWND into the
surface, and use that as the HDC we need for our GdkGLContext.
* Drop the gl_hwnd from GdkWin32Display, as that is really should be
stored in the GdkSurface.
* For functions that were updated, name GdkWin32Display variables as
display_win32 and GdkSurface variables as surface, to unify things.
* Stop calling ReleaseDC() on the HDC that we use for OpenGL, since
they were acquired from HWND's created with CS_OWNDC.
2021-07-19 10:20:09 +00:00
|
|
|
HDC hdc;
|
GDK-Win32/4.0: Enable HiDPI support for Windows
This enables HiDPI support for GTK+ on Windows, so that the
fonts and window look better on HiDPI displays. Notes for the current
work:
-The DPI awareness enabling can be disabled if and only if an application
manifest is not embedded in the app to enable DPI awareness AND a user
compatibility setting is not set to limit DPI awareness for the app, via
the envvar GDK_WIN32_DISABLE_HIDPI. The app manifest/user setting for
DPI awareness will always win against the envvar, and so the HiDPI items
will be always setup in such scenarios, unless DPI awareness is disabled.
-Both automatic detection for the scaling factor and setting the scale
factor using the GDK_SCALE envvar are supported, where the envvar takes
precedence, which will therefore disable automatic scaling when
resolution changes.
-We now default to a per-system DPI awareness model, which means that we
do not handle WM_DPICHANGED, unless one sets the
GDK_WIN32_PER_MONITOR_HIDPI envvar, where notes for it are in the
following point.
-Automatic scaling during WM_DISPLAYCHANGE is handled (DPI setting change of
current monitor) is now supported. WM_DPICHANGED is handled as well,
except that the window positioning during the change of scaling still
needs to be refined, a change in GDK itself may be required for this.
-I am unable to test the wintab items because I don't have such devices
around.
https://bugzilla.gnome.org/show_bug.cgi?id=768081
2016-06-27 05:16:43 +00:00
|
|
|
|
GDK-Win32: Clean up HiDPI support and WGL a bit
Make _gdk_win32_display_get_monitor_scale_factor() less complex, by:
* Drop the preceding underscore.
* Dropping an unused parameter.
* Using a GdkSurface instead of a HWND, as the HWND that we pass into
this function might have been taken from a GdkSurface, which are now
always created with CS_OWNDC. This means if a GdkSurface was passed
in, we ensure that we only acquire the DC from the HWND once, and do
not attempt to call ReleaseDC() on it.
* Store the HDC that we acquire from the GdkSurface's HWND into the
surface, and use that as the HDC we need for our GdkGLContext.
* Drop the gl_hwnd from GdkWin32Display, as that is really should be
stored in the GdkSurface.
* For functions that were updated, name GdkWin32Display variables as
display_win32 and GdkSurface variables as surface, to unify things.
* Stop calling ReleaseDC() on the HDC that we use for OpenGL, since
they were acquired from HWND's created with CS_OWNDC.
2021-07-19 10:20:09 +00:00
|
|
|
if (surface != NULL)
|
GDK-Win32/4.0: Enable HiDPI support for Windows
This enables HiDPI support for GTK+ on Windows, so that the
fonts and window look better on HiDPI displays. Notes for the current
work:
-The DPI awareness enabling can be disabled if and only if an application
manifest is not embedded in the app to enable DPI awareness AND a user
compatibility setting is not set to limit DPI awareness for the app, via
the envvar GDK_WIN32_DISABLE_HIDPI. The app manifest/user setting for
DPI awareness will always win against the envvar, and so the HiDPI items
will be always setup in such scenarios, unless DPI awareness is disabled.
-Both automatic detection for the scaling factor and setting the scale
factor using the GDK_SCALE envvar are supported, where the envvar takes
precedence, which will therefore disable automatic scaling when
resolution changes.
-We now default to a per-system DPI awareness model, which means that we
do not handle WM_DPICHANGED, unless one sets the
GDK_WIN32_PER_MONITOR_HIDPI envvar, where notes for it are in the
following point.
-Automatic scaling during WM_DISPLAYCHANGE is handled (DPI setting change of
current monitor) is now supported. WM_DPICHANGED is handled as well,
except that the window positioning during the change of scaling still
needs to be refined, a change in GDK itself may be required for this.
-I am unable to test the wintab items because I don't have such devices
around.
https://bugzilla.gnome.org/show_bug.cgi?id=768081
2016-06-27 05:16:43 +00:00
|
|
|
{
|
GDK-Win32: Clean up HiDPI support and WGL a bit
Make _gdk_win32_display_get_monitor_scale_factor() less complex, by:
* Drop the preceding underscore.
* Dropping an unused parameter.
* Using a GdkSurface instead of a HWND, as the HWND that we pass into
this function might have been taken from a GdkSurface, which are now
always created with CS_OWNDC. This means if a GdkSurface was passed
in, we ensure that we only acquire the DC from the HWND once, and do
not attempt to call ReleaseDC() on it.
* Store the HDC that we acquire from the GdkSurface's HWND into the
surface, and use that as the HDC we need for our GdkGLContext.
* Drop the gl_hwnd from GdkWin32Display, as that is really should be
stored in the GdkSurface.
* For functions that were updated, name GdkWin32Display variables as
display_win32 and GdkSurface variables as surface, to unify things.
* Stop calling ReleaseDC() on the HDC that we use for OpenGL, since
they were acquired from HWND's created with CS_OWNDC.
2021-07-19 10:20:09 +00:00
|
|
|
if (GDK_WIN32_SURFACE (surface)->hdc == NULL)
|
|
|
|
GDK_WIN32_SURFACE (surface)->hdc = GetDC (GDK_SURFACE_HWND (surface));
|
|
|
|
hdc = GDK_WIN32_SURFACE (surface)->hdc;
|
GDK-Win32/4.0: Enable HiDPI support for Windows
This enables HiDPI support for GTK+ on Windows, so that the
fonts and window look better on HiDPI displays. Notes for the current
work:
-The DPI awareness enabling can be disabled if and only if an application
manifest is not embedded in the app to enable DPI awareness AND a user
compatibility setting is not set to limit DPI awareness for the app, via
the envvar GDK_WIN32_DISABLE_HIDPI. The app manifest/user setting for
DPI awareness will always win against the envvar, and so the HiDPI items
will be always setup in such scenarios, unless DPI awareness is disabled.
-Both automatic detection for the scaling factor and setting the scale
factor using the GDK_SCALE envvar are supported, where the envvar takes
precedence, which will therefore disable automatic scaling when
resolution changes.
-We now default to a per-system DPI awareness model, which means that we
do not handle WM_DPICHANGED, unless one sets the
GDK_WIN32_PER_MONITOR_HIDPI envvar, where notes for it are in the
following point.
-Automatic scaling during WM_DISPLAYCHANGE is handled (DPI setting change of
current monitor) is now supported. WM_DPICHANGED is handled as well,
except that the window positioning during the change of scaling still
needs to be refined, a change in GDK itself may be required for this.
-I am unable to test the wintab items because I don't have such devices
around.
https://bugzilla.gnome.org/show_bug.cgi?id=768081
2016-06-27 05:16:43 +00:00
|
|
|
}
|
GDK-Win32: Clean up HiDPI support and WGL a bit
Make _gdk_win32_display_get_monitor_scale_factor() less complex, by:
* Drop the preceding underscore.
* Dropping an unused parameter.
* Using a GdkSurface instead of a HWND, as the HWND that we pass into
this function might have been taken from a GdkSurface, which are now
always created with CS_OWNDC. This means if a GdkSurface was passed
in, we ensure that we only acquire the DC from the HWND once, and do
not attempt to call ReleaseDC() on it.
* Store the HDC that we acquire from the GdkSurface's HWND into the
surface, and use that as the HDC we need for our GdkGLContext.
* Drop the gl_hwnd from GdkWin32Display, as that is really should be
stored in the GdkSurface.
* For functions that were updated, name GdkWin32Display variables as
display_win32 and GdkSurface variables as surface, to unify things.
* Stop calling ReleaseDC() on the HDC that we use for OpenGL, since
they were acquired from HWND's created with CS_OWNDC.
2021-07-19 10:20:09 +00:00
|
|
|
else
|
|
|
|
hdc = GetDC (NULL);
|
|
|
|
|
|
|
|
/* in case we can't get the DC for the window, return 1 for the scale */
|
|
|
|
if (hdc == NULL)
|
|
|
|
return 1;
|
GDK-Win32/4.0: Enable HiDPI support for Windows
This enables HiDPI support for GTK+ on Windows, so that the
fonts and window look better on HiDPI displays. Notes for the current
work:
-The DPI awareness enabling can be disabled if and only if an application
manifest is not embedded in the app to enable DPI awareness AND a user
compatibility setting is not set to limit DPI awareness for the app, via
the envvar GDK_WIN32_DISABLE_HIDPI. The app manifest/user setting for
DPI awareness will always win against the envvar, and so the HiDPI items
will be always setup in such scenarios, unless DPI awareness is disabled.
-Both automatic detection for the scaling factor and setting the scale
factor using the GDK_SCALE envvar are supported, where the envvar takes
precedence, which will therefore disable automatic scaling when
resolution changes.
-We now default to a per-system DPI awareness model, which means that we
do not handle WM_DPICHANGED, unless one sets the
GDK_WIN32_PER_MONITOR_HIDPI envvar, where notes for it are in the
following point.
-Automatic scaling during WM_DISPLAYCHANGE is handled (DPI setting change of
current monitor) is now supported. WM_DPICHANGED is handled as well,
except that the window positioning during the change of scaling still
needs to be refined, a change in GDK itself may be required for this.
-I am unable to test the wintab items because I don't have such devices
around.
https://bugzilla.gnome.org/show_bug.cgi?id=768081
2016-06-27 05:16:43 +00:00
|
|
|
|
|
|
|
dpix = GetDeviceCaps (hdc, LOGPIXELSX);
|
|
|
|
dpiy = GetDeviceCaps (hdc, LOGPIXELSY);
|
GDK-Win32: Clean up HiDPI support and WGL a bit
Make _gdk_win32_display_get_monitor_scale_factor() less complex, by:
* Drop the preceding underscore.
* Dropping an unused parameter.
* Using a GdkSurface instead of a HWND, as the HWND that we pass into
this function might have been taken from a GdkSurface, which are now
always created with CS_OWNDC. This means if a GdkSurface was passed
in, we ensure that we only acquire the DC from the HWND once, and do
not attempt to call ReleaseDC() on it.
* Store the HDC that we acquire from the GdkSurface's HWND into the
surface, and use that as the HDC we need for our GdkGLContext.
* Drop the gl_hwnd from GdkWin32Display, as that is really should be
stored in the GdkSurface.
* For functions that were updated, name GdkWin32Display variables as
display_win32 and GdkSurface variables as surface, to unify things.
* Stop calling ReleaseDC() on the HDC that we use for OpenGL, since
they were acquired from HWND's created with CS_OWNDC.
2021-07-19 10:20:09 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* If surface is not NULL, the HDC should not be released, since surfaces have
|
|
|
|
* Win32 windows created with CS_OWNDC
|
|
|
|
*/
|
|
|
|
if (surface == NULL)
|
|
|
|
ReleaseDC (NULL, hdc);
|
GDK-Win32/4.0: Enable HiDPI support for Windows
This enables HiDPI support for GTK+ on Windows, so that the
fonts and window look better on HiDPI displays. Notes for the current
work:
-The DPI awareness enabling can be disabled if and only if an application
manifest is not embedded in the app to enable DPI awareness AND a user
compatibility setting is not set to limit DPI awareness for the app, via
the envvar GDK_WIN32_DISABLE_HIDPI. The app manifest/user setting for
DPI awareness will always win against the envvar, and so the HiDPI items
will be always setup in such scenarios, unless DPI awareness is disabled.
-Both automatic detection for the scaling factor and setting the scale
factor using the GDK_SCALE envvar are supported, where the envvar takes
precedence, which will therefore disable automatic scaling when
resolution changes.
-We now default to a per-system DPI awareness model, which means that we
do not handle WM_DPICHANGED, unless one sets the
GDK_WIN32_PER_MONITOR_HIDPI envvar, where notes for it are in the
following point.
-Automatic scaling during WM_DISPLAYCHANGE is handled (DPI setting change of
current monitor) is now supported. WM_DPICHANGED is handled as well,
except that the window positioning during the change of scaling still
needs to be refined, a change in GDK itself may be required for this.
-I am unable to test the wintab items because I don't have such devices
around.
https://bugzilla.gnome.org/show_bug.cgi?id=768081
2016-06-27 05:16:43 +00:00
|
|
|
|
|
|
|
is_scale_acquired = TRUE;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (is_scale_acquired)
|
|
|
|
/* USER_DEFAULT_SCREEN_DPI = 96, in winuser.h */
|
|
|
|
{
|
GDK-Win32: Clean up HiDPI support and WGL a bit
Make _gdk_win32_display_get_monitor_scale_factor() less complex, by:
* Drop the preceding underscore.
* Dropping an unused parameter.
* Using a GdkSurface instead of a HWND, as the HWND that we pass into
this function might have been taken from a GdkSurface, which are now
always created with CS_OWNDC. This means if a GdkSurface was passed
in, we ensure that we only acquire the DC from the HWND once, and do
not attempt to call ReleaseDC() on it.
* Store the HDC that we acquire from the GdkSurface's HWND into the
surface, and use that as the HDC we need for our GdkGLContext.
* Drop the gl_hwnd from GdkWin32Display, as that is really should be
stored in the GdkSurface.
* For functions that were updated, name GdkWin32Display variables as
display_win32 and GdkSurface variables as surface, to unify things.
* Stop calling ReleaseDC() on the HDC that we use for OpenGL, since
they were acquired from HWND's created with CS_OWNDC.
2021-07-19 10:20:09 +00:00
|
|
|
if (display_win32->has_fixed_scale)
|
|
|
|
return display_win32->surface_scale;
|
GDK-Win32/4.0: Enable HiDPI support for Windows
This enables HiDPI support for GTK+ on Windows, so that the
fonts and window look better on HiDPI displays. Notes for the current
work:
-The DPI awareness enabling can be disabled if and only if an application
manifest is not embedded in the app to enable DPI awareness AND a user
compatibility setting is not set to limit DPI awareness for the app, via
the envvar GDK_WIN32_DISABLE_HIDPI. The app manifest/user setting for
DPI awareness will always win against the envvar, and so the HiDPI items
will be always setup in such scenarios, unless DPI awareness is disabled.
-Both automatic detection for the scaling factor and setting the scale
factor using the GDK_SCALE envvar are supported, where the envvar takes
precedence, which will therefore disable automatic scaling when
resolution changes.
-We now default to a per-system DPI awareness model, which means that we
do not handle WM_DPICHANGED, unless one sets the
GDK_WIN32_PER_MONITOR_HIDPI envvar, where notes for it are in the
following point.
-Automatic scaling during WM_DISPLAYCHANGE is handled (DPI setting change of
current monitor) is now supported. WM_DPICHANGED is handled as well,
except that the window positioning during the change of scaling still
needs to be refined, a change in GDK itself may be required for this.
-I am unable to test the wintab items because I don't have such devices
around.
https://bugzilla.gnome.org/show_bug.cgi?id=768081
2016-06-27 05:16:43 +00:00
|
|
|
else
|
|
|
|
return dpix / USER_DEFAULT_SCREEN_DPI > 1 ? dpix / USER_DEFAULT_SCREEN_DPI : 1;
|
|
|
|
}
|
|
|
|
else
|
GDK-Win32: Clean up HiDPI support and WGL a bit
Make _gdk_win32_display_get_monitor_scale_factor() less complex, by:
* Drop the preceding underscore.
* Dropping an unused parameter.
* Using a GdkSurface instead of a HWND, as the HWND that we pass into
this function might have been taken from a GdkSurface, which are now
always created with CS_OWNDC. This means if a GdkSurface was passed
in, we ensure that we only acquire the DC from the HWND once, and do
not attempt to call ReleaseDC() on it.
* Store the HDC that we acquire from the GdkSurface's HWND into the
surface, and use that as the HDC we need for our GdkGLContext.
* Drop the gl_hwnd from GdkWin32Display, as that is really should be
stored in the GdkSurface.
* For functions that were updated, name GdkWin32Display variables as
display_win32 and GdkSurface variables as surface, to unify things.
* Stop calling ReleaseDC() on the HDC that we use for OpenGL, since
they were acquired from HWND's created with CS_OWNDC.
2021-07-19 10:20:09 +00:00
|
|
|
return 1;
|
GDK-Win32/4.0: Enable HiDPI support for Windows
This enables HiDPI support for GTK+ on Windows, so that the
fonts and window look better on HiDPI displays. Notes for the current
work:
-The DPI awareness enabling can be disabled if and only if an application
manifest is not embedded in the app to enable DPI awareness AND a user
compatibility setting is not set to limit DPI awareness for the app, via
the envvar GDK_WIN32_DISABLE_HIDPI. The app manifest/user setting for
DPI awareness will always win against the envvar, and so the HiDPI items
will be always setup in such scenarios, unless DPI awareness is disabled.
-Both automatic detection for the scaling factor and setting the scale
factor using the GDK_SCALE envvar are supported, where the envvar takes
precedence, which will therefore disable automatic scaling when
resolution changes.
-We now default to a per-system DPI awareness model, which means that we
do not handle WM_DPICHANGED, unless one sets the
GDK_WIN32_PER_MONITOR_HIDPI envvar, where notes for it are in the
following point.
-Automatic scaling during WM_DISPLAYCHANGE is handled (DPI setting change of
current monitor) is now supported. WM_DPICHANGED is handled as well,
except that the window positioning during the change of scaling still
needs to be refined, a change in GDK itself may be required for this.
-I am unable to test the wintab items because I don't have such devices
around.
https://bugzilla.gnome.org/show_bug.cgi?id=768081
2016-06-27 05:16:43 +00:00
|
|
|
}
|
|
|
|
|
2017-10-31 04:49:44 +00:00
|
|
|
static gboolean
|
|
|
|
gdk_win32_display_get_setting (GdkDisplay *display,
|
2020-07-24 18:40:36 +00:00
|
|
|
const char *name,
|
2017-10-31 04:49:44 +00:00
|
|
|
GValue *value)
|
|
|
|
{
|
2017-11-17 18:21:24 +00:00
|
|
|
return _gdk_win32_get_setting (name, value);
|
2017-10-31 04:49:44 +00:00
|
|
|
}
|
|
|
|
|
2021-10-07 07:44:38 +00:00
|
|
|
#ifndef EGL_PLATFORM_ANGLE_ANGLE
|
|
|
|
#define EGL_PLATFORM_ANGLE_ANGLE 0x3202
|
|
|
|
#endif
|
|
|
|
|
2022-01-18 02:41:28 +00:00
|
|
|
static GdkGLContext *
|
|
|
|
gdk_win32_display_init_gl (GdkDisplay *display,
|
|
|
|
GError **error)
|
Split out WGL/EGL stuff and simplify things
This commit attempts to split GdkWin32GLContext into two parts, one for
WGL and the other for EGL (ANGLE), and attempts to simplify things a
bit, by:
* We are already creating a Win32 window to capture display changes,
so we can just use that to act as our dummy window that we use to
find out the pixel format that the system supports for WGL. We also
use it to obtain the dummy legacy WGL context that we will always
require to create our more advanced Core WGL contexts.
* Like what is done in X11, store up the WGL pixel format or the
EGLConfig in our GdkWin32Display.
* Ensure we do not create the dummy WGL context unnecessarily.
In this way, we can successfully create the WGL/EGL contexts, however
there are some issues at this point:
* For WGL, the code successfully initializes and realizes the WGL
Contexts, but for some reason things became invisible. When running
gtk4-demo, this can be verified by seeing the mouse cursor changing
when moved to spots where one can resize the window, although they
were invisible.
* For EGL, the code initializes EGL but could not realize the EGL
context as shaders failed to compile. It seems like the shader issue
is definitely outside the scope of this MR.
2021-07-14 09:46:31 +00:00
|
|
|
{
|
2021-10-07 07:44:38 +00:00
|
|
|
GdkWin32Display *display_win32 = GDK_WIN32_DISPLAY (display);
|
2022-01-18 02:41:28 +00:00
|
|
|
HDC init_gl_hdc = NULL;
|
2023-04-26 04:16:37 +00:00
|
|
|
GdkGLContext *context;
|
2021-10-07 07:44:38 +00:00
|
|
|
|
2021-11-08 07:37:08 +00:00
|
|
|
/*
|
|
|
|
* No env vars set, do the regular GL initialization, first WGL and then EGL,
|
2021-07-19 02:48:03 +00:00
|
|
|
* as WGL is the more tried-and-tested configuration.
|
Split out WGL/EGL stuff and simplify things
This commit attempts to split GdkWin32GLContext into two parts, one for
WGL and the other for EGL (ANGLE), and attempts to simplify things a
bit, by:
* We are already creating a Win32 window to capture display changes,
so we can just use that to act as our dummy window that we use to
find out the pixel format that the system supports for WGL. We also
use it to obtain the dummy legacy WGL context that we will always
require to create our more advanced Core WGL contexts.
* Like what is done in X11, store up the WGL pixel format or the
EGLConfig in our GdkWin32Display.
* Ensure we do not create the dummy WGL context unnecessarily.
In this way, we can successfully create the WGL/EGL contexts, however
there are some issues at this point:
* For WGL, the code successfully initializes and realizes the WGL
Contexts, but for some reason things became invisible. When running
gtk4-demo, this can be verified by seeing the mouse cursor changing
when moved to spots where one can resize the window, although they
were invisible.
* For EGL, the code initializes EGL but could not realize the EGL
context as shaders failed to compile. It seems like the shader issue
is definitely outside the scope of this MR.
2021-07-14 09:46:31 +00:00
|
|
|
*/
|
|
|
|
|
2021-11-08 07:37:08 +00:00
|
|
|
#ifdef HAVE_EGL
|
|
|
|
/*
|
2022-01-18 02:41:28 +00:00
|
|
|
* Disable defaulting to EGL as EGL is used more as a compatibility layer
|
2021-11-08 07:37:08 +00:00
|
|
|
* on Windows rather than being a native citizen on Windows
|
|
|
|
*/
|
2022-09-22 01:12:22 +00:00
|
|
|
if (gdk_display_get_debug_flags (display) & (GDK_DEBUG_GL_EGL|GDK_DEBUG_GL_GLES))
|
2022-01-17 08:11:27 +00:00
|
|
|
{
|
gdkglcontext-win32-wgl.c: Fix using wglChoosePixelFormatARB()
If we are querying the best supported pixel format for our HDC via
wglChoosePixelFormatARB() (i.e. we have the WGL_ARB_pixel_format extension),
it may return a pixel format that is different from the pixel format that we
used for the dummy context that we have setup, in order to, well, run
wglChoosePixelFormatARB(), which sadly requires a WGL context (HGLRC) to be
current in order to use it, which means the dummy HDC already has a pixel
format that has been set (notice that each HDC is only allowed to have its
pixel format to be set *once*). This is notably the case on Intel display
drivers.
Since we are emulating surfaceless GL contexts, we are using the dummy GL
context (and thus dummy HDC that is derived from the notification HWND used in
GdkWin32Display) for doing that, we would get into trouble if th actual HDC
from the GdkWin32Surface has a different pixel format set.
So, as a result, in order to fix this situation, we do the following:
* Create yet another dummy HWND in order to grab the HDC to query for the
capabilities the GL drivers support, and to call wglChoosePixelFormatARB() as
appropriate (or ChoosePixelFormat()) for the final pixel format that we use.
* Ditch the dummy GL context, HDC and HWND after obtaining the pixel format.
* Then set the final pixel format that we obtained onto the HDC that is derived
from the HWND used in GdkWin32Display for notifications, which will become our
new dummy HDC.
* Create a new dummy HGLRC for use with the new dummy HDC to emulate surfaceless
GL support.
2023-05-03 09:58:54 +00:00
|
|
|
init_gl_hdc = GetDC (display_win32->hwnd);
|
|
|
|
|
2022-01-18 02:41:28 +00:00
|
|
|
if (gdk_display_init_egl (display,
|
|
|
|
EGL_PLATFORM_ANGLE_ANGLE,
|
|
|
|
init_gl_hdc,
|
|
|
|
FALSE,
|
|
|
|
error))
|
|
|
|
{
|
2022-01-18 16:18:07 +00:00
|
|
|
return g_object_new (GDK_TYPE_WIN32_GL_CONTEXT_EGL,
|
2022-01-18 02:41:28 +00:00
|
|
|
"display", display,
|
2023-04-13 15:22:21 +00:00
|
|
|
"allowed-apis", GDK_GL_API_GLES,
|
2022-01-18 02:41:28 +00:00
|
|
|
NULL);
|
|
|
|
}
|
2022-01-18 16:18:07 +00:00
|
|
|
else
|
|
|
|
g_clear_error (error);
|
2021-10-07 07:44:38 +00:00
|
|
|
}
|
2022-01-18 16:18:07 +00:00
|
|
|
#endif
|
Split out WGL/EGL stuff and simplify things
This commit attempts to split GdkWin32GLContext into two parts, one for
WGL and the other for EGL (ANGLE), and attempts to simplify things a
bit, by:
* We are already creating a Win32 window to capture display changes,
so we can just use that to act as our dummy window that we use to
find out the pixel format that the system supports for WGL. We also
use it to obtain the dummy legacy WGL context that we will always
require to create our more advanced Core WGL contexts.
* Like what is done in X11, store up the WGL pixel format or the
EGLConfig in our GdkWin32Display.
* Ensure we do not create the dummy WGL context unnecessarily.
In this way, we can successfully create the WGL/EGL contexts, however
there are some issues at this point:
* For WGL, the code successfully initializes and realizes the WGL
Contexts, but for some reason things became invisible. When running
gtk4-demo, this can be verified by seeing the mouse cursor changing
when moved to spots where one can resize the window, although they
were invisible.
* For EGL, the code initializes EGL but could not realize the EGL
context as shaders failed to compile. It seems like the shader issue
is definitely outside the scope of this MR.
2021-07-14 09:46:31 +00:00
|
|
|
|
2023-04-26 04:16:37 +00:00
|
|
|
context = gdk_win32_display_init_wgl (display, error);
|
gdkglcontext-win32-wgl.c: Fix using wglChoosePixelFormatARB()
If we are querying the best supported pixel format for our HDC via
wglChoosePixelFormatARB() (i.e. we have the WGL_ARB_pixel_format extension),
it may return a pixel format that is different from the pixel format that we
used for the dummy context that we have setup, in order to, well, run
wglChoosePixelFormatARB(), which sadly requires a WGL context (HGLRC) to be
current in order to use it, which means the dummy HDC already has a pixel
format that has been set (notice that each HDC is only allowed to have its
pixel format to be set *once*). This is notably the case on Intel display
drivers.
Since we are emulating surfaceless GL contexts, we are using the dummy GL
context (and thus dummy HDC that is derived from the notification HWND used in
GdkWin32Display) for doing that, we would get into trouble if th actual HDC
from the GdkWin32Surface has a different pixel format set.
So, as a result, in order to fix this situation, we do the following:
* Create yet another dummy HWND in order to grab the HDC to query for the
capabilities the GL drivers support, and to call wglChoosePixelFormatARB() as
appropriate (or ChoosePixelFormat()) for the final pixel format that we use.
* Ditch the dummy GL context, HDC and HWND after obtaining the pixel format.
* Then set the final pixel format that we obtained onto the HDC that is derived
from the HWND used in GdkWin32Display for notifications, which will become our
new dummy HDC.
* Create a new dummy HGLRC for use with the new dummy HDC to emulate surfaceless
GL support.
2023-05-03 09:58:54 +00:00
|
|
|
|
2023-04-26 04:16:37 +00:00
|
|
|
if (context)
|
|
|
|
return context;
|
Split out WGL/EGL stuff and simplify things
This commit attempts to split GdkWin32GLContext into two parts, one for
WGL and the other for EGL (ANGLE), and attempts to simplify things a
bit, by:
* We are already creating a Win32 window to capture display changes,
so we can just use that to act as our dummy window that we use to
find out the pixel format that the system supports for WGL. We also
use it to obtain the dummy legacy WGL context that we will always
require to create our more advanced Core WGL contexts.
* Like what is done in X11, store up the WGL pixel format or the
EGLConfig in our GdkWin32Display.
* Ensure we do not create the dummy WGL context unnecessarily.
In this way, we can successfully create the WGL/EGL contexts, however
there are some issues at this point:
* For WGL, the code successfully initializes and realizes the WGL
Contexts, but for some reason things became invisible. When running
gtk4-demo, this can be verified by seeing the mouse cursor changing
when moved to spots where one can resize the window, although they
were invisible.
* For EGL, the code initializes EGL but could not realize the EGL
context as shaders failed to compile. It seems like the shader issue
is definitely outside the scope of this MR.
2021-07-14 09:46:31 +00:00
|
|
|
|
2022-01-18 16:18:07 +00:00
|
|
|
#ifdef HAVE_EGL
|
|
|
|
g_clear_error (error);
|
2022-01-17 08:11:27 +00:00
|
|
|
|
gdkglcontext-win32-wgl.c: Fix using wglChoosePixelFormatARB()
If we are querying the best supported pixel format for our HDC via
wglChoosePixelFormatARB() (i.e. we have the WGL_ARB_pixel_format extension),
it may return a pixel format that is different from the pixel format that we
used for the dummy context that we have setup, in order to, well, run
wglChoosePixelFormatARB(), which sadly requires a WGL context (HGLRC) to be
current in order to use it, which means the dummy HDC already has a pixel
format that has been set (notice that each HDC is only allowed to have its
pixel format to be set *once*). This is notably the case on Intel display
drivers.
Since we are emulating surfaceless GL contexts, we are using the dummy GL
context (and thus dummy HDC that is derived from the notification HWND used in
GdkWin32Display) for doing that, we would get into trouble if th actual HDC
from the GdkWin32Surface has a different pixel format set.
So, as a result, in order to fix this situation, we do the following:
* Create yet another dummy HWND in order to grab the HDC to query for the
capabilities the GL drivers support, and to call wglChoosePixelFormatARB() as
appropriate (or ChoosePixelFormat()) for the final pixel format that we use.
* Ditch the dummy GL context, HDC and HWND after obtaining the pixel format.
* Then set the final pixel format that we obtained onto the HDC that is derived
from the HWND used in GdkWin32Display for notifications, which will become our
new dummy HDC.
* Create a new dummy HGLRC for use with the new dummy HDC to emulate surfaceless
GL support.
2023-05-03 09:58:54 +00:00
|
|
|
init_gl_hdc = GetDC (display_win32->hwnd);
|
2022-01-18 16:18:07 +00:00
|
|
|
if (gdk_display_init_egl (display,
|
|
|
|
EGL_PLATFORM_ANGLE_ANGLE,
|
|
|
|
init_gl_hdc,
|
|
|
|
TRUE,
|
|
|
|
error))
|
|
|
|
{
|
|
|
|
return g_object_new (GDK_TYPE_WIN32_GL_CONTEXT_EGL,
|
|
|
|
"display", display,
|
|
|
|
NULL);
|
2022-01-18 02:41:28 +00:00
|
|
|
|
2022-01-17 08:11:27 +00:00
|
|
|
}
|
Split out WGL/EGL stuff and simplify things
This commit attempts to split GdkWin32GLContext into two parts, one for
WGL and the other for EGL (ANGLE), and attempts to simplify things a
bit, by:
* We are already creating a Win32 window to capture display changes,
so we can just use that to act as our dummy window that we use to
find out the pixel format that the system supports for WGL. We also
use it to obtain the dummy legacy WGL context that we will always
require to create our more advanced Core WGL contexts.
* Like what is done in X11, store up the WGL pixel format or the
EGLConfig in our GdkWin32Display.
* Ensure we do not create the dummy WGL context unnecessarily.
In this way, we can successfully create the WGL/EGL contexts, however
there are some issues at this point:
* For WGL, the code successfully initializes and realizes the WGL
Contexts, but for some reason things became invisible. When running
gtk4-demo, this can be verified by seeing the mouse cursor changing
when moved to spots where one can resize the window, although they
were invisible.
* For EGL, the code initializes EGL but could not realize the EGL
context as shaders failed to compile. It seems like the shader issue
is definitely outside the scope of this MR.
2021-07-14 09:46:31 +00:00
|
|
|
#endif
|
|
|
|
|
2022-01-18 16:18:07 +00:00
|
|
|
return NULL;
|
Split out WGL/EGL stuff and simplify things
This commit attempts to split GdkWin32GLContext into two parts, one for
WGL and the other for EGL (ANGLE), and attempts to simplify things a
bit, by:
* We are already creating a Win32 window to capture display changes,
so we can just use that to act as our dummy window that we use to
find out the pixel format that the system supports for WGL. We also
use it to obtain the dummy legacy WGL context that we will always
require to create our more advanced Core WGL contexts.
* Like what is done in X11, store up the WGL pixel format or the
EGLConfig in our GdkWin32Display.
* Ensure we do not create the dummy WGL context unnecessarily.
In this way, we can successfully create the WGL/EGL contexts, however
there are some issues at this point:
* For WGL, the code successfully initializes and realizes the WGL
Contexts, but for some reason things became invisible. When running
gtk4-demo, this can be verified by seeing the mouse cursor changing
when moved to spots where one can resize the window, although they
were invisible.
* For EGL, the code initializes EGL but could not realize the EGL
context as shaders failed to compile. It seems like the shader issue
is definitely outside the scope of this MR.
2021-07-14 09:46:31 +00:00
|
|
|
}
|
|
|
|
|
2021-07-14 04:19:52 +00:00
|
|
|
/**
|
|
|
|
* gdk_win32_display_get_egl_display:
|
|
|
|
* @display: (type GdkWin32Display): a Win32 display
|
|
|
|
*
|
|
|
|
* Retrieves the EGL display connection object for the given GDK display.
|
|
|
|
*
|
|
|
|
* Returns: (nullable): the EGL display
|
2022-08-25 13:33:25 +00:00
|
|
|
*
|
|
|
|
* Since: 4.4
|
2021-07-14 04:19:52 +00:00
|
|
|
*/
|
|
|
|
gpointer
|
|
|
|
gdk_win32_display_get_egl_display (GdkDisplay *display)
|
|
|
|
{
|
|
|
|
g_return_val_if_fail (GDK_IS_WIN32_DISPLAY (display), NULL);
|
|
|
|
|
2021-10-07 07:44:38 +00:00
|
|
|
return gdk_display_get_egl_display (display);
|
2021-07-14 04:19:52 +00:00
|
|
|
}
|
|
|
|
|
2011-01-02 10:51:25 +00:00
|
|
|
static void
|
|
|
|
gdk_win32_display_class_init (GdkWin32DisplayClass *klass)
|
|
|
|
{
|
|
|
|
GObjectClass *object_class = G_OBJECT_CLASS (klass);
|
|
|
|
GdkDisplayClass *display_class = GDK_DISPLAY_CLASS (klass);
|
|
|
|
|
|
|
|
object_class->dispose = gdk_win32_display_dispose;
|
|
|
|
object_class->finalize = gdk_win32_display_finalize;
|
|
|
|
|
2023-04-21 03:41:48 +00:00
|
|
|
display_class->toplevel_type = GDK_TYPE_WIN32_TOPLEVEL;
|
|
|
|
display_class->popup_type = GDK_TYPE_WIN32_POPUP;
|
2018-04-12 14:48:31 +00:00
|
|
|
display_class->cairo_context_type = GDK_TYPE_WIN32_CAIRO_CONTEXT;
|
2011-01-02 10:51:25 +00:00
|
|
|
|
|
|
|
display_class->get_name = gdk_win32_display_get_name;
|
|
|
|
display_class->beep = gdk_win32_display_beep;
|
2011-10-27 14:56:40 +00:00
|
|
|
display_class->sync = gdk_win32_display_sync;
|
2011-01-02 10:51:25 +00:00
|
|
|
display_class->flush = gdk_win32_display_flush;
|
|
|
|
display_class->has_pending = _gdk_win32_display_has_pending;
|
|
|
|
display_class->queue_events = _gdk_win32_display_queue_events;
|
|
|
|
|
|
|
|
//? display_class->get_app_launch_context = _gdk_win32_display_get_app_launch_context;
|
|
|
|
|
|
|
|
display_class->get_next_serial = gdk_win32_display_get_next_serial;
|
|
|
|
display_class->notify_startup_complete = gdk_win32_display_notify_startup_complete;
|
|
|
|
|
|
|
|
display_class->get_keymap = _gdk_win32_display_get_keymap;
|
2015-04-29 07:31:08 +00:00
|
|
|
|
2020-05-13 05:00:35 +00:00
|
|
|
display_class->get_monitors = gdk_win32_display_get_monitors;
|
2016-04-20 07:36:00 +00:00
|
|
|
|
2016-12-28 14:25:07 +00:00
|
|
|
#ifdef GDK_RENDERING_VULKAN
|
|
|
|
display_class->vk_context_type = GDK_TYPE_WIN32_VULKAN_CONTEXT;
|
|
|
|
display_class->vk_extension_name = VK_KHR_WIN32_SURFACE_EXTENSION_NAME;
|
|
|
|
#endif
|
|
|
|
|
2017-10-31 04:49:44 +00:00
|
|
|
display_class->get_setting = gdk_win32_display_get_setting;
|
2017-11-17 22:42:12 +00:00
|
|
|
display_class->set_cursor_theme = gdk_win32_display_set_cursor_theme;
|
Split out WGL/EGL stuff and simplify things
This commit attempts to split GdkWin32GLContext into two parts, one for
WGL and the other for EGL (ANGLE), and attempts to simplify things a
bit, by:
* We are already creating a Win32 window to capture display changes,
so we can just use that to act as our dummy window that we use to
find out the pixel format that the system supports for WGL. We also
use it to obtain the dummy legacy WGL context that we will always
require to create our more advanced Core WGL contexts.
* Like what is done in X11, store up the WGL pixel format or the
EGLConfig in our GdkWin32Display.
* Ensure we do not create the dummy WGL context unnecessarily.
In this way, we can successfully create the WGL/EGL contexts, however
there are some issues at this point:
* For WGL, the code successfully initializes and realizes the WGL
Contexts, but for some reason things became invisible. When running
gtk4-demo, this can be verified by seeing the mouse cursor changing
when moved to spots where one can resize the window, although they
were invisible.
* For EGL, the code initializes EGL but could not realize the EGL
context as shaders failed to compile. It seems like the shader issue
is definitely outside the scope of this MR.
2021-07-14 09:46:31 +00:00
|
|
|
display_class->init_gl = gdk_win32_display_init_gl;
|
2017-10-31 04:49:44 +00:00
|
|
|
|
2018-03-20 10:40:08 +00:00
|
|
|
_gdk_win32_surfaceing_init ();
|
2011-01-02 10:51:25 +00:00
|
|
|
}
|