2014-12-17 04:32:04 +00:00
|
|
|
/*
|
|
|
|
* gdkdisplay-win32.h
|
|
|
|
*
|
|
|
|
* Copyright 2014 Chun-wei Fan <fanc999@yahoo.com.tw>
|
|
|
|
*
|
|
|
|
* This library is free software; you can redistribute it and/or
|
|
|
|
* modify it under the terms of the GNU Library 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
|
|
|
|
* Library General Public License for more details.
|
|
|
|
*
|
|
|
|
* You should have received a copy of the GNU Library General Public
|
|
|
|
* License along with this library. If not, see <http://www.gnu.org/licenses/>.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include "gdkdisplayprivate.h"
|
|
|
|
|
2023-03-31 19:11:10 +00:00
|
|
|
#pragma once
|
2014-12-17 04:32:04 +00:00
|
|
|
|
2018-03-24 12:52:25 +00:00
|
|
|
#include "gdkwin32screen.h"
|
GDK W32: New cursor class
Instead of now-unused GdkWin32Cursor class (a subclass of GdkCursor),
add a stand-alone GdkWin32HCursor class that is a wrapper around
HCURSOR handle.
On creation it's given a display instance, a HCURSOR handle and a boolean
that indicates whether the HCURSOR handle can or cannot be destroyed
(this depends on how the handle was obtained).
That information is stored in a hash table inside the GdkWin32Display
singleton, each entry of that table has reference count.
When the GdkWin32HCursor object is finalized, it reduces the reference
count on the table entry in the GdkWin32Display. When it's created,
it either adds such an entry or refs an existing one.
This way two pieces of code (or the same piece of code called
multiple times) that independently obtain the same HCURSOR from the OS
will get to different GdkWin32HCursor instances, but GdkWin32Display
will know that both use the same handle.
Once the reference count reaches 0 on the table entry, it is freed
and the handle (if destroyable) is put on the destruction list,
and an idle destruction function is queued.
If the same handle is once again registered for use before the
idle destructior is invoked (this happens, for example, when
an old cursor is destroyed and then replaced with a new one),
the handle gets removed from the destruction list.
The destructor just calls DestroyCursor() on each handle, calling
SetCursor(NULL) before doing that when the handle is in use.
This ensures that SetCursor(NULL) (which will cause cursor to disappear,
which is bad by itself, and which will also cause flickering if the
cursor is set to a non-NULL again shortly afterward)
is almost never called, unless GTK messes up and keeps using a cursor
beyond its lifetime.
This scheme also ensures that non-destructable cursors are not destroyed.
It's also possible to call _gdk_win32_display_hcursor_ref()
and _gdk_win32_display_hcursor_unref() manually instead of creating
GdkWin32HCursor objects, but that is not recommended.
2018-03-29 23:38:05 +00:00
|
|
|
#include "gdkwin32cursor.h"
|
2018-07-31 10:11:26 +00:00
|
|
|
|
2023-04-25 17:17:07 +00:00
|
|
|
#include "gdkglversionprivate.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
|
2018-03-24 12:52: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
|
|
|
/* Define values used to set DPI-awareness */
|
|
|
|
typedef enum _GdkWin32ProcessDpiAwareness {
|
|
|
|
PROCESS_DPI_UNAWARE = 0,
|
|
|
|
PROCESS_SYSTEM_DPI_AWARE = 1,
|
2019-12-04 10:41:05 +00:00
|
|
|
PROCESS_PER_MONITOR_DPI_AWARE = 2,
|
|
|
|
PROCESS_PER_MONITOR_DPI_AWARE_V2 = 3, /* Newer HiDPI type for Windows 10 1607+ */
|
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;
|
|
|
|
|
2019-12-04 10:41:05 +00:00
|
|
|
/* From https://docs.microsoft.com/en-US/windows/win32/hidpi/dpi-awareness-context */
|
|
|
|
/* DPI_AWARENESS_CONTEXT is declared by DEFINE_HANDLE */
|
|
|
|
#ifndef DPI_AWARENESS_CONTEXT_UNAWARE
|
|
|
|
#define DPI_AWARENESS_CONTEXT_UNAWARE (HANDLE)-1
|
|
|
|
#endif
|
|
|
|
|
|
|
|
#ifndef DPI_AWARENESS_CONTEXT_SYSTEM_AWARE
|
|
|
|
#define DPI_AWARENESS_CONTEXT_SYSTEM_AWARE (HANDLE)-2
|
|
|
|
#endif
|
|
|
|
|
|
|
|
#ifndef DPI_AWARENESS_CONTEXT_PER_MONITOR_AWARE_V2
|
|
|
|
#define DPI_AWARENESS_CONTEXT_PER_MONITOR_AWARE_V2 (HANDLE)-4
|
|
|
|
#endif
|
|
|
|
|
2018-03-24 12:52:25 +00:00
|
|
|
typedef enum _GdkWin32MonitorDpiType {
|
|
|
|
MDT_EFFECTIVE_DPI = 0,
|
|
|
|
MDT_ANGULAR_DPI = 1,
|
|
|
|
MDT_RAW_DPI = 2,
|
|
|
|
MDT_DEFAULT = MDT_EFFECTIVE_DPI
|
|
|
|
} GdkWin32MonitorDpiType;
|
|
|
|
|
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
|
|
|
/* APIs from shcore.dll */
|
|
|
|
typedef HRESULT (WINAPI *funcSetProcessDpiAwareness) (GdkWin32ProcessDpiAwareness value);
|
|
|
|
typedef HRESULT (WINAPI *funcGetProcessDpiAwareness) (HANDLE handle, GdkWin32ProcessDpiAwareness *awareness);
|
|
|
|
typedef HRESULT (WINAPI *funcGetDpiForMonitor) (HMONITOR monitor,
|
|
|
|
GdkWin32MonitorDpiType dpi_type,
|
|
|
|
UINT *dpi_x,
|
|
|
|
UINT *dpi_y);
|
|
|
|
|
|
|
|
typedef struct _GdkWin32ShcoreFuncs
|
|
|
|
{
|
|
|
|
HMODULE hshcore;
|
|
|
|
funcSetProcessDpiAwareness setDpiAwareFunc;
|
|
|
|
funcGetProcessDpiAwareness getDpiAwareFunc;
|
|
|
|
funcGetDpiForMonitor getDpiForMonitorFunc;
|
|
|
|
} GdkWin32ShcoreFuncs;
|
|
|
|
|
|
|
|
/* DPI awareness APIs from user32.dll */
|
|
|
|
typedef BOOL (WINAPI *funcSetProcessDPIAware) (void);
|
|
|
|
typedef BOOL (WINAPI *funcIsProcessDPIAware) (void);
|
|
|
|
|
2019-12-04 10:41:05 +00:00
|
|
|
/*
|
|
|
|
* funcSPDAC is SetProcessDpiAwarenessContext() and
|
|
|
|
* funcGTDAC is GetThreadDpiAwarenessContext() and
|
|
|
|
* funcADACE is AreDpiAwarenessContextsEqual() provided by user32.dll, on
|
|
|
|
* Windows 10 Creator Edition and later.
|
|
|
|
* Treat HANDLE as void*, for convenience, since DPI_AWARENESS_CONTEXT is
|
|
|
|
* declared using DEFINE_HANDLE.
|
|
|
|
*/
|
|
|
|
typedef BOOL (WINAPI *funcSPDAC) (void *);
|
|
|
|
typedef HANDLE (WINAPI *funcGTDAC) (void);
|
|
|
|
typedef BOOL (WINAPI *funcADACE) (void *, void *);
|
|
|
|
|
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
|
|
|
typedef struct _GdkWin32User32DPIFuncs
|
|
|
|
{
|
|
|
|
funcSetProcessDPIAware setDpiAwareFunc;
|
|
|
|
funcIsProcessDPIAware isDpiAwareFunc;
|
2019-12-04 10:41:05 +00:00
|
|
|
funcSPDAC setPDAC;
|
|
|
|
funcGTDAC getTDAC;
|
|
|
|
funcADACE areDACEqual;
|
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
|
|
|
} GdkWin32User32DPIFuncs;
|
|
|
|
|
2021-08-19 14:29:45 +00:00
|
|
|
typedef enum {
|
|
|
|
GDK_WIN32_TABLET_INPUT_API_NONE,
|
|
|
|
GDK_WIN32_TABLET_INPUT_API_WINTAB,
|
|
|
|
GDK_WIN32_TABLET_INPUT_API_WINPOINTER
|
|
|
|
} GdkWin32TabletInputAPI;
|
|
|
|
|
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
|
|
|
typedef struct
|
|
|
|
{
|
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
|
|
|
HWND hwnd;
|
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
|
|
|
HDC hdc;
|
|
|
|
HGLRC hglrc;
|
|
|
|
} GdkWin32GLDummyContextWGL;
|
|
|
|
|
2014-12-17 04:32:04 +00:00
|
|
|
struct _GdkWin32Display
|
|
|
|
{
|
|
|
|
GdkDisplay display;
|
|
|
|
|
2017-11-17 18:46:45 +00:00
|
|
|
GdkWin32Screen *screen;
|
2016-01-15 19:45:45 +00:00
|
|
|
|
2015-05-13 07:45:40 +00:00
|
|
|
Win32CursorTheme *cursor_theme;
|
2020-07-24 18:40:36 +00:00
|
|
|
char *cursor_theme_name;
|
2015-05-13 07:45:40 +00:00
|
|
|
int cursor_theme_size;
|
|
|
|
|
2015-10-29 16:20:54 +00:00
|
|
|
HWND hwnd;
|
|
|
|
|
2014-12-17 04:32:04 +00:00
|
|
|
/* WGL/OpenGL Items */
|
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
|
|
|
GdkWin32GLDummyContextWGL dummy_context_wgl;
|
2014-12-17 04:32:04 +00:00
|
|
|
|
2020-05-13 02:44:06 +00:00
|
|
|
GListModel *monitors;
|
2016-04-20 07:36:00 +00:00
|
|
|
|
2014-12-17 04:32:04 +00:00
|
|
|
guint hasWglARBCreateContext : 1;
|
|
|
|
guint hasWglEXTSwapControl : 1;
|
|
|
|
guint hasWglOMLSyncControl : 1;
|
2016-10-14 11:04:49 +00:00
|
|
|
guint hasWglARBPixelFormat : 1;
|
2024-08-12 16:36:52 +00:00
|
|
|
guint hasGlWINSwapHint : 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
|
|
|
|
2021-10-07 07:26:49 +00:00
|
|
|
#ifdef HAVE_EGL
|
2018-07-31 10:11:26 +00:00
|
|
|
guint hasEglKHRCreateContext : 1;
|
|
|
|
guint hasEglSurfacelessContext : 1;
|
|
|
|
EGLint egl_min_swap_interval;
|
|
|
|
#endif
|
|
|
|
|
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
|
|
|
/* HiDPI Items */
|
|
|
|
guint have_at_least_win81 : 1;
|
|
|
|
GdkWin32ProcessDpiAwareness dpi_aware_type;
|
|
|
|
guint has_fixed_scale : 1;
|
2018-03-20 11:05:26 +00:00
|
|
|
guint 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
|
|
|
|
|
|
|
GdkWin32ShcoreFuncs shcore_funcs;
|
|
|
|
GdkWin32User32DPIFuncs user32_dpi_funcs;
|
2021-08-19 14:29:45 +00:00
|
|
|
|
|
|
|
GdkWin32TabletInputAPI tablet_input_api;
|
|
|
|
|
2018-03-29 23:40:32 +00:00
|
|
|
/* Cursor Items (GdkCursor->GdkWin32HCursor) */
|
2017-11-07 07:39:48 +00:00
|
|
|
GHashTable *cursors;
|
2018-03-29 23:40:32 +00:00
|
|
|
/* The cursor that is used by current grab (if any) */
|
|
|
|
GdkWin32HCursor *grab_cursor;
|
GDK W32: New cursor class
Instead of now-unused GdkWin32Cursor class (a subclass of GdkCursor),
add a stand-alone GdkWin32HCursor class that is a wrapper around
HCURSOR handle.
On creation it's given a display instance, a HCURSOR handle and a boolean
that indicates whether the HCURSOR handle can or cannot be destroyed
(this depends on how the handle was obtained).
That information is stored in a hash table inside the GdkWin32Display
singleton, each entry of that table has reference count.
When the GdkWin32HCursor object is finalized, it reduces the reference
count on the table entry in the GdkWin32Display. When it's created,
it either adds such an entry or refs an existing one.
This way two pieces of code (or the same piece of code called
multiple times) that independently obtain the same HCURSOR from the OS
will get to different GdkWin32HCursor instances, but GdkWin32Display
will know that both use the same handle.
Once the reference count reaches 0 on the table entry, it is freed
and the handle (if destroyable) is put on the destruction list,
and an idle destruction function is queued.
If the same handle is once again registered for use before the
idle destructior is invoked (this happens, for example, when
an old cursor is destroyed and then replaced with a new one),
the handle gets removed from the destruction list.
The destructor just calls DestroyCursor() on each handle, calling
SetCursor(NULL) before doing that when the handle is in use.
This ensures that SetCursor(NULL) (which will cause cursor to disappear,
which is bad by itself, and which will also cause flickering if the
cursor is set to a non-NULL again shortly afterward)
is almost never called, unless GTK messes up and keeps using a cursor
beyond its lifetime.
This scheme also ensures that non-destructable cursors are not destroyed.
It's also possible to call _gdk_win32_display_hcursor_ref()
and _gdk_win32_display_hcursor_unref() manually instead of creating
GdkWin32HCursor objects, but that is not recommended.
2018-03-29 23:38:05 +00:00
|
|
|
/* HCURSOR -> GdkWin32HCursorTableEntry */
|
|
|
|
GHashTable *cursor_reftable;
|
|
|
|
/* ID of the idle callback scheduled to destroy cursors */
|
|
|
|
guint idle_cursor_destructor_id;
|
|
|
|
|
|
|
|
/* A list of cursor handles slated for destruction. */
|
|
|
|
GList *cursors_for_destruction;
|
2018-03-24 16:39:13 +00:00
|
|
|
|
|
|
|
/* Message filters */
|
|
|
|
GList *filters;
|
2019-05-07 07:09:03 +00:00
|
|
|
|
|
|
|
/* Running CPU items */
|
|
|
|
guint running_on_arm64 : 1;
|
2014-12-17 04:32:04 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
struct _GdkWin32DisplayClass
|
|
|
|
{
|
|
|
|
GdkDisplayClass display_class;
|
|
|
|
};
|
|
|
|
|
2020-05-13 02:44:06 +00:00
|
|
|
void _gdk_win32_display_init_monitors (GdkWin32Display *display);
|
2016-04-20 07:36:00 +00:00
|
|
|
|
|
|
|
GPtrArray *_gdk_win32_display_get_monitor_list (GdkWin32Display *display);
|
|
|
|
|
2016-10-29 02:37:20 +00:00
|
|
|
void gdk_win32_display_check_composited (GdkWin32Display *display);
|
|
|
|
|
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
|
|
|
guint 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
|
|
|
|
2018-03-24 16:39:13 +00:00
|
|
|
typedef struct _GdkWin32MessageFilter GdkWin32MessageFilter;
|
|
|
|
|
|
|
|
struct _GdkWin32MessageFilter
|
|
|
|
{
|
|
|
|
GdkWin32MessageFilterFunc function;
|
|
|
|
gpointer data;
|
|
|
|
gboolean removed;
|
|
|
|
guint ref_count;
|
|
|
|
};
|
|
|
|
|