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"
|
|
|
|
|
|
|
|
#ifndef __GDK_DISPLAY__WIN32_H__
|
|
|
|
#define __GDK_DISPLAY__WIN32_H__
|
|
|
|
|
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
|
|
|
|
|
|
|
#ifdef GDK_WIN32_ENABLE_EGL
|
|
|
|
# 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;
|
|
|
|
|
2019-05-07 07:09:03 +00:00
|
|
|
/* Detect running architecture */
|
|
|
|
typedef BOOL (WINAPI *funcIsWow64Process2) (HANDLE, USHORT *, USHORT *);
|
|
|
|
typedef struct _GdkWin32KernelCPUFuncs
|
|
|
|
{
|
|
|
|
funcIsWow64Process2 isWow64Process2;
|
|
|
|
} GdkWin32KernelCPUFuncs;
|
|
|
|
|
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
|
|
|
|
{
|
|
|
|
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;
|
|
|
|
int wgl_pixel_format;
|
2014-12-17 04:32:04 +00:00
|
|
|
guint gl_version;
|
|
|
|
|
2018-07-31 10:11:26 +00:00
|
|
|
#ifdef GDK_WIN32_ENABLE_EGL
|
|
|
|
/* EGL (Angle) Items */
|
|
|
|
guint egl_version;
|
|
|
|
EGLDisplay egl_disp;
|
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
|
|
|
EGLConfig egl_config;
|
2018-07-31 10:11:26 +00:00
|
|
|
HDC hdc_egl_temp;
|
|
|
|
#endif
|
|
|
|
|
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;
|
|
|
|
guint hasWglARBmultisample : 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
|
|
|
|
2018-07-31 10:11:26 +00:00
|
|
|
#ifdef GDK_WIN32_ENABLE_EGL
|
|
|
|
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;
|
2017-11-07 07:39:48 +00:00
|
|
|
|
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;
|
|
|
|
GdkWin32KernelCPUFuncs cpu_funcs;
|
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;
|
|
|
|
};
|
|
|
|
|
2014-12-17 04:32:04 +00:00
|
|
|
#endif /* __GDK_DISPLAY__WIN32_H__ */
|