If alpha is 255, we use rgb() instead of rgba(), not if alpha is 0.
This makes the title bar gradient go from fully transparent to blue
rather than black to blue..
When we send an anchor rectangle with a width or
height of 0, mutter reponds with "Invalid anchor
rectangle size". So, don't do that.
This was seen as sudden disappearance of gtk4-demo
when you click the fishbowl benchmark all the way
through to the menubuttons.
Fixes: #3027
We might break the loop early, e.g. if we're unmapped before the round
trip finishes, and to avoid the callback to write to invalid stack
memory, destroy the callback so it won't be invoked.
Fixes: #3026
GTK will not up front know how to correctly calculate a size, since it
will not be able to reliably predict the constraints that may exist
where it will be mapped.
Thus, to handle this, calculate the size of the toplevel by having GDK
emitting a signal called 'compute-size' that will contain information
needed for computing a toplevel window size.
This signal may be emitted at any time, e.g. during
gdk_toplevel_present(), or spontaneously if constraints change.
This also drops the max size from the toplevel layout, while moving the
min size from the toplevel layout struct to the struct passed via the
signal,
This needs changes to a test case where we make sure we process
GDK_CONFIGURE etc, which means we also needs to show the window and
process all pending events in the test-focus-chain test case.
gdk_gl_context_has_framebuffer_blit() and gdk_gl_context_has_frame_terminator()
were only used by by GDK/Win32, and they do not provide performance advantages
in GTK master, so clean up the code a bit by dropping them.
Use gdk_surface_get_geometry() to get the correct x and y coordinates of the
window that we are resizing, so that the window does not reposition itself
automatically at the top-left corner at resizing as we to used hard-code the x
and y coordinates to 0.
By doing so, we ensure that resizes of windows will work on Vulkan renderer, by
first calling gdk_win32_surface_handle_queued_move_resize() before we proceed
as usual
Use the shared function that was added in the previous commit, to simplify
things.
Also make gdk_win32_surface_get_queued_window_rect() and
gdk_win32_surface_apply_queued_move_resize() back into static functions, since
they are now used only by the code in gdksurface-win32.c
Since we need to deal with queued moves and resizes in the Cairo, GL and Vulkan
draw contexts, and the logic involved in all three of these are largely
similar, add a function gdk_win32_surface_handle_queued_move_resize() that will
handle this, which will be shared between these three types of draw contexts.
Move gdk_win32_surface_get_queued_window_rect() and
gdk_win32_surface_apply_queued_move_resize() to gdksurface-win32.c, since these
functions are not only used for Cairo draw contexts, but is also used for GL
draw contexts, and will be used for Vulkan draw contexts.
Don't get the default display when we compute the Aerosnap region, but instead
get it from the underlying GdkSurface that we are using for the computation.
Also, don't unref the monitors that we obtain from the display in the wrong
place, which was why we had crashes whenever we triggered AeroSnap code (and we
are actually not supposed to do that as they are owned by the GdkDisplay that
is owned by the GdkSurface we are using), and this will eliminate lots of
criticals that are spewed as a result.
This check used to read if (grab || device_type != GDK_DEVICE_TYPE_PHYSICAL),
the grab check was only reserved to physical devices, which the current
pointer device definitely doesn't act like. So the condition was "fixed" the
wrong way around, and the latter check is now moot, so the condition should
really go away. We always want to check the new toplevel under the pointer
here.
Fixes: https://gitlab.gnome.org/GNOME/gtk/-/issues/2970
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.
Like the other backends, we ought to create our WGL/EGL GL contexts like
the following:
"Create a global GL context that connects all GL contexts on a display
and lets us share textures between them."
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.
We need to use GL_BGRA instead of GL_RGBA when doing glReadPixels() on
EGL on Windows (ANGLE) so that the red and blue bits won't be displayed
inverted.
Also fix the logic where we determine whether to bit blit or redraw
everything.
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.
...EGL support needs to be explicitly enabled during the build of
libepoxy on Windows as it is not enabled by default on Windows.
With this, we can add an EGL renderer for Windows that make use of
Google's libANGLE, which is a library that translates OpenGL/ES calls
to Direct3D 9/11, which will provide better hardware compatibility
on Windows and would act as one of the foundations to resolve issue #105.
It's not a portable API, so remove it. The corresponding backend
specific functions are still available, if they were implemented, e.g.
gdk_macos_monitor_get_workarea() and gdk_x11_monitor_get_workarea().
Make GdkEvents hold a single GdkDevice. This device is closer to
the logical device conceptually, although it must be sufficient for
device checks (i.e. GdkInputSource), which makes it similar to the
physical devices.
Make the logical devices have a more accurate GdkInputSource where
needed, and conflate the event devices altogether.
Besides the implicit x/y assumptions, devices don't have axes. Those
are actually provided by the GdkDeviceTool driving the device, and
different tools may have different axes.
It does not make sense to offer this API that can change beneath
someone's feet, we now have gdk_device_tool_get_axes() which is static
to the tool.
Looking at the xf86-input-wacom driver code, this is not even a thing
anymore. Drop this device type, in modern days there's
GDK_DEVICE_TOOL_TYPE_MOUSE for this.
When converting DisplayLink frame presentation times, we need to take into
account the arch-specific types. This tracks changes in GNOME/GLib!1566 so
that precision is not lost.
