Commit Graph

31 Commits

Author SHA1 Message Date
Luca Bacci
c02bae9e08
Move the _gdk_win32_pointer_input_api global variable into GdkWin32Display 2021-08-19 16:29:45 +02:00
Chun-wei Fan
6c00117119 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-22 16:28:16 +02:00
Chun-wei Fan
ac64d2d910 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 18:30:42 +08:00
Chun-wei Fan
20388f83f5 GDK-Win32: Use SetProcessDpiAwarenessContext() where available
This allows us to use DPI_AWARENESS_CONTEXT_PER_MONITOR_AWARE_V2 for the
DPI awareness mode, which will help us to better support use cases with
multiple monitors.  This is actualy a more advaned version of the
current PROCESS_PER_MONITOR_DPI_AWARE via using SetProcessDpiAwareness().

Note that this is not enabled by default, but also enabled via using
GDK_WIN32_PER_MONITOR_HIDPI, as in the PROCESS_PER_MONITOR_DPI_AWARE
case.

Note also, that appliation compatibility settings and DPI-awareness
manifests takes precedence over this API call, as before.
2020-07-31 23:20:25 +08:00
Chun-wei Fan
a481733b40 GDK/Win32: Force GLES if running on ARM64
If GLES support is enabled on Windows, force GLES mode if we are running
on a ARM64 version of Windows (i.e. Windows 10 for ARM).

This is required as ARM64 versions of Windows only provide a software
implementation of OpenGL 1.1/1.2, which is not enough for our purposes.
Thus, we could make instead use the GLES support provided via Google's
libANGLE (which emulates OpenGL/ES 3 with Direct3D 9/11), so that we
can run GtkGLArea programs under OpenGL/ES in ARM64 versions of Windows.

Note that eventually we could update the libepoxy build files for Windows
to not check nor enable WGL when building for ARM64 Windows, as the WGL
items do not work, although they do build.
2020-07-30 14:30:13 +08:00
Chun-wei Fan
257fd990d1 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.
2020-07-30 14:26:33 +08:00
Benjamin Otte
d375dce9f5 Replace "gchar" with "char" 2020-07-25 00:47:36 +02:00
Benjamin Otte
d7266b25ba Replace "gint" with "int" 2020-07-25 00:47:36 +02:00
Benjamin Otte
bc88f01165 win32: Use a GListStore for the monitors 2020-05-13 06:45:08 +02:00
Руслан Ижбулатов
a82d67bb7d 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:59:23 +00:00
Руслан Ижбулатов
d8da6d38db 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:59:14 +00:00
Руслан Ижбулатов
ef01e6ee52 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-29 17:43:55 +00:00
Руслан Ижбулатов
54a4307128 GDK W32: Another massive clipboard and DnD update
Rename GdkWin32Selection to GdkWin32Clipdrop, since GdkSelection
is mostly gone, and the word "selection" does not reflect the
functionality of this object too well.

Clipboard is now handled by a separate thread, most of the code for
it now lives in gdkclipdrop-win32.c, gdkclipboard-win32.c just uses
clipdrop as a backend.

The DnD source part is also put into a thread.
The DnD target part does not spin the main loop, it just
emits a GDK event and returns a default value if it doesn't get a reply
by the time the event is processed.

Both clipboard and DnD use a new GOutputStream subclass to get data
from GTK and put it into a HGLOBAL.

GdkWin32DragContext is split into GdkWin32DragContext and GdkWin32DropContext,
anticipating a similar change that slated to happen to GdkDragContext.

OLE2 DnD protocol is now used by default, set GDK_WIN32_OLE2_DND envvar to 0
to make GDK use the old LOCAL and DROPFILES protocols.

https://bugzilla.gnome.org/show_bug.cgi?id=773299
2018-03-29 17:43:53 +00:00
Руслан Ижбулатов
35305bfc85 GDK W32: move GdkWin32MonitorDpiType to a different header
https://bugzilla.gnome.org/show_bug.cgi?id=773299
2018-03-28 08:33:07 +00:00
Alexander Larsson
9a7e721181 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 12:05:26 +01:00
Chun-wei Fan
e076cc7b1f GDK/Win32: Fix build after GDK Root Window and DND changes
Ensure that things build again, and instead use the Windows API to
acquire the screen dimensions (note: this may need to be scaled for
HiDPI, but since I do not own a WinTab-based device, I will need to
keep the dimensions as-is for now).

Also update the gdkdnd-win32.c code to use formats rather than targets.

https://bugzilla.gnome.org/show_bug.cgi?id=773299
2017-11-22 22:18:28 +08:00
Matthias Clasen
0f2d7d41f1 win32: Remove remaining uses of GdkScreen 2017-11-17 13:47:15 -05:00
Chun-wei Fan
c06b1cc103 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-09 08:30:09 +08:00
Chun-wei Fan
3228149892 gdk/win32: Fix Win32 GL Context switching
Since on Windows we need to use a good amount of temporary GL contexts,
we need to switch back to the original GL contexts we were using when
we are done with the temporary GL contexts, otherwise multi-GL windows
will cause confusions causing display artifacts and crashes.

Also, use the GdkWin32GLContext::gl_hdc consistently throughout
the code and remove the GdkWin32Display::gl_hdc as Lukas K pointed out
that GdkWin32Display::gl_hdc becomes out-of-date and so the HDC that the
GL context is bound to becomes incorrect in sceanarios using multiple
windows with GtkGLArea/GdkGLArea items (which would cause the artifacts in
programs that use multiple windows with GtkGLArea/GdkGLArea items, and it
turns out that GdkWin32Display::gl_hdc is actually not necessary to help
keep track of the HDCs we use for our GL contexts.

This will also fix on Windows with GDK_GL=always, or when GSK's gl
renderer is used.

Partly based on patch from Lukas K <lu@0x83.eu>

https://bugzilla.gnome.org/show_bug.cgi?id=789213
2017-11-04 10:39:03 +08:00
Chun-wei Fan
6abd65c83b 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-11-04 18:14:48 +08:00
Benjamin Otte
d249e77bcb 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 04:49:47 +02:00
Chun-wei Fan
b960008955 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-28 15:56:49 +08:00
Руслан Ижбулатов
026cb53875 win32: Port to new monitor api 2016-04-27 23:18:16 -04:00
Paolo Borelli
4a6f8a065a gdk: remove the display->list_devices vfunc
gdk_display_list_devices is deprecated and all the backends
implement the same fallback by delegating to the device manager
and caching the list (caching it is needed since the method does
not transfer ownership of the container).
The compat code can be shared among all backends and we can
initialize the list lazily only in the case someone calls the
deprecated method.

https://bugzilla.gnome.org/show_bug.cgi?id=762891
2016-02-29 21:53:58 +01:00
Paolo Borelli
7047099fd8 Win32: fold the gdkinput.c file in gdkdisplay-win32.c
This is similar to what is done in the X11 and wayland backends.
It also gets rid of the _gdk_input_devices global variable
2016-02-22 21:45:08 +01:00
Ignacio Casal Quinteiro
f6cc3be118 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 12:35:31 +01:00
Ignacio Casal Quinteiro
1f5f3ca41b win32: destroy clipboard notification window on dispose
The clipboard uses a hidden window to get some specific events.
The window was created but never destroyed on dispose.
2015-11-12 17:09:25 +01:00
Paolo Borelli
8606e57910 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-31 15:31:11 +01:00
Руслан Ижбулатов
26c24328d5 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-20 08:42:24 +00:00
Chun-wei Fan
36245b7058 GDK-Win32: Drop Some Unused Items
There were a bit of unused items from the GDK-Win32 work on GL support, so
drop them.
2014-12-22 11:25:49 +08:00
Chun-wei Fan
536fa88cd8 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 16:07:02 +08:00