AuroraMiddleware/gtk
1
0
Fork 1
mirror of https://gitlab.gnome.org/GNOME/gtk.git synced 2024-11-10 10:50:10 +00:00
Code Issues Projects Releases Wiki Activity
cf0175ffce
gtk/gdk/win32/gdkdisplay-win32.h

163 lines
4.7 KiB
C
Raw Normal View History

Add OpenGL Support for the GDK Windows Backend This adds support for OpenGL to the GDK Windows backend using the WGL API calls, which enables programs that uses the GTK+ GLArea widgets to work on Windows as well. This also adds a simple utility function to query for the version of OpenGL that is supported by the Windows system, like the one provided by the X11 backend. Many thanks to Alex (and Emmanuele, who started the OpenGL integration in GTK+) who offered advice and help along the way, as well as the X11 and Wayland backend for this work to refer to and to model upon. https://bugzilla.gnome.org/show_bug.cgi?id=740795
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__
GDK W32: move GdkWin32MonitorDpiType to a different header https://bugzilla.gnome.org/show_bug.cgi?id=773299
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"
Add a EGL renderer (via ANGLE) for Windows This is for adding a EGL-based renderer which is done via the ANGLE project, which translate EGL calls to Direct3D 9/11. This is done as a possible solution to issue #105, especially for cases where the needed full GL extensions to map OpenGL to Direct3D is unavailable or unreliable, or when the OpenGL implementation from the graphics drivers are problematic. To enable this, do the following: -Build ANGLE and ensure the ANGLE libEGL.dll and libGLESv2.dll are available. A sufficiently-recent ANGLE is needed for things to work correctly--note that the copy of ANGLE that is included in qtbase-5.10.1 is sufficient. ANGLE is licensed under a BSD 3-clause license. -Build libepoxy on Windows with EGL support enabled. -Currently, prior to running GTK+ programs, the GDK_DEBUG envvar needs to be set with gl-gles as at least one of the flags. Known issues: -Only OpenGL ES 3 is supported, ANGLE's ES 2 does not support the needed extensions, notably GL_OES_vertex_array_object, but its ES 3 support is sufficient. -There is no autodetection or fallback mechanism to enable using EGL/Angle automatically yet. There are no plans to do this in this commit.
2018-07-31 10:11:26 +00:00
#ifdef GDK_WIN32_ENABLE_EGL
# include <epoxy/egl.h>
#endif
GDK W32: move GdkWin32MonitorDpiType to a different header https://bugzilla.gnome.org/show_bug.cgi?id=773299
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,
PROCESS_PER_MONITOR_DPI_AWARE = 2
} GdkWin32ProcessDpiAwareness;
GDK W32: move GdkWin32MonitorDpiType to a different header https://bugzilla.gnome.org/show_bug.cgi?id=773299
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);
typedef struct _GdkWin32User32DPIFuncs
{
funcSetProcessDPIAware setDpiAwareFunc;
funcIsProcessDPIAware isDpiAwareFunc;
} GdkWin32User32DPIFuncs;
Add OpenGL Support for the GDK Windows Backend This adds support for OpenGL to the GDK Windows backend using the WGL API calls, which enables programs that uses the GTK+ GLArea widgets to work on Windows as well. This also adds a simple utility function to query for the version of OpenGL that is supported by the Windows system, like the one provided by the X11 backend. Many thanks to Alex (and Emmanuele, who started the OpenGL integration in GTK+) who offered advice and help along the way, as well as the X11 and Wayland backend for this work to refer to and to model upon. https://bugzilla.gnome.org/show_bug.cgi?id=740795
2014-12-17 04:32:04 +00:00
struct _GdkWin32Display
{
GdkDisplay display;
win32: Remove remaining uses of GdkScreen
2017-11-17 18:46:45 +00:00
GdkWin32Screen *screen;
win32: get rid of _gdk_screen global variable The screen is part of the display so it should be belong to it.
2016-01-15 19:45:45 +00:00
GDK: Add cursor theme support to W32 backend Load themed cursors from the same places they are loaded on freedesktop systems, but use W32 API functions to do so (works for .cur/.ani cursors instead of X cursors). Refactor the code for cursor handling. Prefer loading cursors by name. Do not load actual cursors when loading the theme. Find the files and remember the arguments/calls for loading them instead. Keeping HCURSOR instance in the hashmap would result in multiple GdkCursors using the same HCURSOR. Given that we use DestroyCursor() to off them, this would cause problems (at the very least - DestroyCursor() would fail). Store GdkCursor instances in a cache. Update cached cursors when theme changes. Recognize "system" theme as a special (and default) case. When it is set, prefer system cursors and fall back to Adwaita cursors and (as a last resort) built-in X cursors. Otherwise prefer theme cursors and fall back to system and X cursors. Force GTK to use "left_ptr" cursor when no cursor is set. Using NULL makes it use the system default "arrow", which is not the intended behaviour when a non-system theme is selected. Ignore cursor size setting and query the OS for the required cursor size, as Windows (almost) does not allow setting cursors of arbitrary size. https://bugzilla.gnome.org/show_bug.cgi?id=749287
2015-05-13 07:45:40 +00:00
Win32CursorTheme *cursor_theme;
Replace "gchar" with "char"
2020-07-24 18:40:36 +00:00
char *cursor_theme_name;
GDK: Add cursor theme support to W32 backend Load themed cursors from the same places they are loaded on freedesktop systems, but use W32 API functions to do so (works for .cur/.ani cursors instead of X cursors). Refactor the code for cursor handling. Prefer loading cursors by name. Do not load actual cursors when loading the theme. Find the files and remember the arguments/calls for loading them instead. Keeping HCURSOR instance in the hashmap would result in multiple GdkCursors using the same HCURSOR. Given that we use DestroyCursor() to off them, this would cause problems (at the very least - DestroyCursor() would fail). Store GdkCursor instances in a cache. Update cached cursors when theme changes. Recognize "system" theme as a special (and default) case. When it is set, prefer system cursors and fall back to Adwaita cursors and (as a last resort) built-in X cursors. Otherwise prefer theme cursors and fall back to system and X cursors. Force GTK to use "left_ptr" cursor when no cursor is set. Using NULL makes it use the system default "arrow", which is not the intended behaviour when a non-system theme is selected. Ignore cursor size setting and query the OS for the required cursor size, as Windows (almost) does not allow setting cursors of arbitrary size. https://bugzilla.gnome.org/show_bug.cgi?id=749287
2015-05-13 07:45:40 +00:00
int cursor_theme_size;
win32: handle WM_DISPLAYCHANGE globally Instead of handling WM_DISPLAYCHANGE on every GdkWindow, only handle it on an ad-hoc hidden window we create when opening the display. This has two reasons: 1) we want emit the display::size-changed signal even if there are no gtk windows currently open 2) we want to emit the signal just once and not once for every window https://bugzilla.gnome.org/show_bug.cgi?id=757324
2015-10-29 16:20:54 +00:00
HWND hwnd;
Add OpenGL Support for the GDK Windows Backend This adds support for OpenGL to the GDK Windows backend using the WGL API calls, which enables programs that uses the GTK+ GLArea widgets to work on Windows as well. This also adds a simple utility function to query for the version of OpenGL that is supported by the Windows system, like the one provided by the X11 backend. Many thanks to Alex (and Emmanuele, who started the OpenGL integration in GTK+) who offered advice and help along the way, as well as the X11 and Wayland backend for this work to refer to and to model upon. https://bugzilla.gnome.org/show_bug.cgi?id=740795
2014-12-17 04:32:04 +00:00
/* WGL/OpenGL Items */
guint have_wgl : 1;
guint gl_version;
HWND gl_hwnd;
Add a EGL renderer (via ANGLE) for Windows This is for adding a EGL-based renderer which is done via the ANGLE project, which translate EGL calls to Direct3D 9/11. This is done as a possible solution to issue #105, especially for cases where the needed full GL extensions to map OpenGL to Direct3D is unavailable or unreliable, or when the OpenGL implementation from the graphics drivers are problematic. To enable this, do the following: -Build ANGLE and ensure the ANGLE libEGL.dll and libGLESv2.dll are available. A sufficiently-recent ANGLE is needed for things to work correctly--note that the copy of ANGLE that is included in qtbase-5.10.1 is sufficient. ANGLE is licensed under a BSD 3-clause license. -Build libepoxy on Windows with EGL support enabled. -Currently, prior to running GTK+ programs, the GDK_DEBUG envvar needs to be set with gl-gles as at least one of the flags. Known issues: -Only OpenGL ES 3 is supported, ANGLE's ES 2 does not support the needed extensions, notably GL_OES_vertex_array_object, but its ES 3 support is sufficient. -There is no autodetection or fallback mechanism to enable using EGL/Angle automatically yet. There are no plans to do this in this commit.
2018-07-31 10:11:26 +00:00
#ifdef GDK_WIN32_ENABLE_EGL
/* EGL (Angle) Items */
guint have_egl : 1;
guint egl_version;
EGLDisplay egl_disp;
HDC hdc_egl_temp;
#endif
win32: Use a GListStore for the monitors
2020-05-13 02:44:06 +00:00
GListModel *monitors;
win32: Port to new monitor api
2016-04-20 07:36:00 +00:00
Add OpenGL Support for the GDK Windows Backend This adds support for OpenGL to the GDK Windows backend using the WGL API calls, which enables programs that uses the GTK+ GLArea widgets to work on Windows as well. This also adds a simple utility function to query for the version of OpenGL that is supported by the Windows system, like the one provided by the X11 backend. Many thanks to Alex (and Emmanuele, who started the OpenGL integration in GTK+) who offered advice and help along the way, as well as the X11 and Wayland backend for this work to refer to and to model upon. https://bugzilla.gnome.org/show_bug.cgi?id=740795
2014-12-17 04:32:04 +00:00
guint hasWglARBCreateContext : 1;
guint hasWglEXTSwapControl : 1;
guint hasWglOMLSyncControl : 1;
GDK-Win32/4.0: Improve GL on Windows Update the GDKGL implementation: -Allow legacy contexts to be created. -Use finer-grained attributes to ask for a pixel format when possible, which also adds support for anti-aliasing In fact the changes here are required for GTKGL to work properly on Windows for 4.x. Note that creation of gles contexts is not done here, as the system does not support such contexts directly on Windows, but only through means such as ANGLE, which is a totally different issue here. https://bugzilla.gnome.org/show_bug.cgi?id=773528
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
Add a EGL renderer (via ANGLE) for Windows This is for adding a EGL-based renderer which is done via the ANGLE project, which translate EGL calls to Direct3D 9/11. This is done as a possible solution to issue #105, especially for cases where the needed full GL extensions to map OpenGL to Direct3D is unavailable or unreliable, or when the OpenGL implementation from the graphics drivers are problematic. To enable this, do the following: -Build ANGLE and ensure the ANGLE libEGL.dll and libGLESv2.dll are available. A sufficiently-recent ANGLE is needed for things to work correctly--note that the copy of ANGLE that is included in qtbase-5.10.1 is sufficient. ANGLE is licensed under a BSD 3-clause license. -Build libepoxy on Windows with EGL support enabled. -Currently, prior to running GTK+ programs, the GDK_DEBUG envvar needs to be set with gl-gles as at least one of the flags. Known issues: -Only OpenGL ES 3 is supported, ANGLE's ES 2 does not support the needed extensions, notably GL_OES_vertex_array_object, but its ES 3 support is sufficient. -There is no autodetection or fallback mechanism to enable using EGL/Angle automatically yet. There are no plans to do this in this commit.
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;
GdkSurface: Rename various functions and variables This is an automatic rename of various things related to the window->surface rename. Public symbols changed by this is: GDK_MODE_WINDOW gdk_device_get_window_at_position gdk_device_get_window_at_position_double gdk_device_get_last_event_window gdk_display_get_monitor_at_window gdk_drag_context_get_source_window gdk_drag_context_get_dest_window gdk_drag_context_get_drag_window gdk_draw_context_get_window gdk_drawing_context_get_window gdk_gl_context_get_window gdk_synthesize_window_state gdk_surface_get_window_type gdk_x11_display_set_window_scale gsk_renderer_new_for_window gsk_renderer_get_window gtk_text_view_buffer_to_window_coords gtk_tree_view_convert_widget_to_bin_window_coords gtk_tree_view_convert_tree_to_bin_window_coords The commands that generated this are: git sed -f g "GDK window" "GDK surface" git sed -f g window_impl surface_impl (cd gdk; git sed -f g impl_window impl_surface) git sed -f g WINDOW_IMPL SURFACE_IMPL git sed -f g GDK_MODE_WINDOW GDK_MODE_SURFACE git sed -f g gdk_draw_context_get_window gdk_draw_context_get_surface git sed -f g gdk_drawing_context_get_window gdk_drawing_context_get_surface git sed -f g gdk_gl_context_get_window gdk_gl_context_get_surface git sed -f g gsk_renderer_get_window gsk_renderer_get_surface git sed -f g gsk_renderer_new_for_window gsk_renderer_new_for_surface (cd gdk; git sed -f g window_type surface_type) git sed -f g gdk_surface_get_window_type gdk_surface_get_surface_type git sed -f g window_at_position surface_at_position git sed -f g event_window event_surface git sed -f g window_coord surface_coord git sed -f g window_state surface_state git sed -f g window_cursor surface_cursor git sed -f g window_scale surface_scale git sed -f g window_events surface_events git sed -f g monitor_at_window monitor_at_surface git sed -f g window_under_pointer surface_under_pointer (cd gdk; git sed -f g for_window for_surface) git sed -f g window_anchor surface_anchor git sed -f g WINDOW_IS_TOPLEVEL SURFACE_IS_TOPLEVEL git sed -f g native_window native_surface git sed -f g source_window source_surface git sed -f g dest_window dest_surface git sed -f g drag_window drag_surface git sed -f g input_window input_surface git checkout NEWS* po-properties po docs/reference/gtk/migrating-3to4.xml
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;
Win32: Re-work cursor handling Like the X11 and Wayland backends, re-work how the cursors are being handled. So, we use a hash table to cache up the HCURSORS that we create along the way. We still need to cache up the icon/cursor themes since this is something that is not part of Windows but was added on to support icon/cursor themes such as Adwaita on Windows, but should be in-line with what is going on in GdkCursor. Also, remove the _gdk_grab_cursor global variable in gdkprivate-win32.h, and replace it with another variable in the GdkWin32Display structure, to make things cleaner in the process. https://bugzilla.gnome.org/show_bug.cgi?id=773299
2017-11-07 07:39:48 +00:00
GDK W32: Use the new cursor class This makes all the code use the new cursor class instead of raw HCURSOR handles.
2018-03-29 23:40:32 +00:00
/* Cursor Items (GdkCursor->GdkWin32HCursor) */
Win32: Re-work cursor handling Like the X11 and Wayland backends, re-work how the cursors are being handled. So, we use a hash table to cache up the HCURSORS that we create along the way. We still need to cache up the icon/cursor themes since this is something that is not part of Windows but was added on to support icon/cursor themes such as Adwaita on Windows, but should be in-line with what is going on in GdkCursor. Also, remove the _gdk_grab_cursor global variable in gdkprivate-win32.h, and replace it with another variable in the GdkWin32Display structure, to make things cleaner in the process. https://bugzilla.gnome.org/show_bug.cgi?id=773299
2017-11-07 07:39:48 +00:00
GHashTable *cursors;
GDK W32: Use the new cursor class This makes all the code use the new cursor class instead of raw HCURSOR handles.
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;
GDK W32: Adapt to event filter removal Add a new W32 backend-specific message filtering mechanism. Works roughly the same way old event filtering did, but without events (events are GDK/X11 concept that never really made sense on W32), so there's no functionality for 'altering' events being emitted. If an event needs to be emitted in response to a message do it yourself. Implemented like this, it should give better performance than if we were to use GLib signals for this, since W32 sends a LOT of messages (unlike X11, which doesn't send events as often) all the time, and invoking the signal machinery on *each* message would probably be bad. https://bugzilla.gnome.org/show_bug.cgi?id=773299
2018-03-24 16:39:13 +00:00
/* Message filters */
GList *filters;
Add OpenGL Support for the GDK Windows Backend This adds support for OpenGL to the GDK Windows backend using the WGL API calls, which enables programs that uses the GTK+ GLArea widgets to work on Windows as well. This also adds a simple utility function to query for the version of OpenGL that is supported by the Windows system, like the one provided by the X11 backend. Many thanks to Alex (and Emmanuele, who started the OpenGL integration in GTK+) who offered advice and help along the way, as well as the X11 and Wayland backend for this work to refer to and to model upon. https://bugzilla.gnome.org/show_bug.cgi?id=740795
2014-12-17 04:32:04 +00:00
};
struct _GdkWin32DisplayClass
{
GdkDisplayClass display_class;
};
win32: Use a GListStore for the monitors
2020-05-13 02:44:06 +00:00
void _gdk_win32_display_init_monitors (GdkWin32Display *display);
win32: Port to new monitor api
2016-04-20 07:36:00 +00:00
GPtrArray *_gdk_win32_display_get_monitor_list (GdkWin32Display *display);
API: screen: Remove gdk_screen_is_composited() Switch code to use gdk_display_is_composited() instead. The new code also doesn't use a vfunc to query the property but rather requires the backend to call set_composited()/set_rgba() to change the value.
2016-10-29 02:37:20 +00:00
void gdk_win32_display_check_composited (GdkWin32Display *display);
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_display_get_monitor_scale_factor (GdkWin32Display *win32_display,
HMONITOR hmonitor,
HWND hwnd,
Replace "gint" with "int"
2020-07-24 13:54:49 +00:00
int *dpi);
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 W32: Adapt to event filter removal Add a new W32 backend-specific message filtering mechanism. Works roughly the same way old event filtering did, but without events (events are GDK/X11 concept that never really made sense on W32), so there's no functionality for 'altering' events being emitted. If an event needs to be emitted in response to a message do it yourself. Implemented like this, it should give better performance than if we were to use GLib signals for this, since W32 sends a LOT of messages (unlike X11, which doesn't send events as often) all the time, and invoking the signal machinery on *each* message would probably be bad. https://bugzilla.gnome.org/show_bug.cgi?id=773299
2018-03-24 16:39:13 +00:00
typedef struct _GdkWin32MessageFilter GdkWin32MessageFilter;
struct _GdkWin32MessageFilter
{
GdkWin32MessageFilterFunc function;
gpointer data;
gboolean removed;
guint ref_count;
};
Add OpenGL Support for the GDK Windows Backend This adds support for OpenGL to the GDK Windows backend using the WGL API calls, which enables programs that uses the GTK+ GLArea widgets to work on Windows as well. This also adds a simple utility function to query for the version of OpenGL that is supported by the Windows system, like the one provided by the X11 backend. Many thanks to Alex (and Emmanuele, who started the OpenGL integration in GTK+) who offered advice and help along the way, as well as the X11 and Wayland backend for this work to refer to and to model upon. https://bugzilla.gnome.org/show_bug.cgi?id=740795
2014-12-17 04:32:04 +00:00
#endif /* __GDK_DISPLAY__WIN32_H__ */
Reference in New Issue Copy Permalink