We don't need the OpenGL view to be transparent if the window itself
is not transparent. This has the potential to speed up the compositing
of the GL view onto the NSWindow.
This fixes an issue where we would ignore events with Y delta
and no X delta while scrolling due to a typo when checking for
any delta.
This fixes deceleration of kinetic scrolling on the macOS backend.
Fixes#3418
We need to keep this consistent so that we can look things up
faster in other places. Therefore, just take the hit here and clear
the entire list ensuring prev/next poniters are cleared.
This isn't done automatically for us, so we need to synthesize it in
our hide helper.
With this commit, we properly re-focus the new main/key window after
we have closed a transient-for window.
We need to re-attach to the transient-for window whenever we present or
we risk getting placed behind the window by the display server. Apparently
that setting does not persist across a hide of the NSWindow.
Once we figure out what is going on with textures, changes are we'll be
able to let this stay a zero rect. But that is still a bit up in the air right now.
The Cairo implementation for the Macos backend uses a toplevel
window with full transparency and a series of NSView to create opaque
regions. This improves compositor performance because it allows the
display server to avoid costly blends.
However, we want to ensure we clip better when exposing the
transparent region so that we only expose the shadows/corners as
necessary.
This typedef was not used in any public APIs, and is
only used in the MacOS backend. It is not worth preserving
as public API, move it to the only user.
This implements the basics for a GdkGLContext on macOS. Currently, rendering
only is fully working for the GskCairoRenderer case where we read back pixels
into a cairo surface for rendering. More work on synchronization is required for
the GL on GskGLRenderer case.
When we attempt to render a surface itself with GL, the context will ensure that
the new GdkMacosGLView is placed within the NSWindow. In other cases, we
use a dummy NSView and NSWindow for backing the NSOpenGLContext to
ensure that we can get accelerated drawing.
This gets GtkGLArea working when running with GSK_RENDERER=cairo.
This helps a situation where the window contents has not changed
in time for a drawing. Setting the texture gravity helps that side or
corner to be less jittery while moving.
Ideally, we can get to a point where we are synchronized and keeping
up with drawing fast enough to not need this. That may require some
work to drive frame clocks from drawRect: though.
This was incorrectly reporting the toplevel surface instead of the
popup surface that was placed above it. This fixes event delivery
to popups for selecting menu items and more.
When querying a device, we need to ensure we are providing coordinates
in the coordinate system of the surface. Further, we need to actually
provide the button and keyboard state.
This fixes some issues related to dragging scrollbars and selecting list
box rows more reliably.
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.
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().
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.
This is fairly substantial rewrite of the GDK backend for quartz and
renamed to macOS to allow for a greenfield implementation.
Many things have come across from the quartz implementation fairly
intact such as the eventloop integration design and discovery of
event windows from the NSEvent.
However much has been changed to fit in with the new GDK design and
how removal of child GdkWindow have been completely eliminated.
Furthermore, the new GdkPopup allows for regular NSWindow to be used
to provide popovers unlike the previous implementation.
The object design more closely follows the ideal for a GDK backend.
Views have been broken out into subclasses so that we can support
multiple GSK renderer paths such as GL and Cairo (and Metal in the
future). However mixed mode GL and Cairo will not be supported. Currently
only the Cairo renderer has been implemented.
A new frame clock implementation using CVDisplayLink provides more
accurate information about when to draw drawing the next frame. Some
testing will need to be done here to understand the power implications
of this.
This implementation has also gained edge snapping for CSD windows. Some
work was also done to ensure that CSD windows have opaque regions
registered with the display server.
** This is still very much a work-in-progress **
Some outstanding work that needs to be done:
- Finish a GL context for macOS and alternate NSView for GL rendering
(possibly using speciailized CALayer for OpenGL).
- Input rework to ensure that we don't loose remapping of keys that was
dropped from GDK during GTK 4 development.
- Make sure input methods continue to work.
- Drag-n-Drop is still very much a work in progress
- High resolution input scrolling needs various work in GDK to land
first before we can plumb that to NSEvent.
- gtk/ has a number of things based on GDK_WINDOWING_QUARTZ that need
to be updated to use the macOS backend.
But this is good enough to start playing with and breaking things which
is what I'd like to see.
