One may be using IJG libjpeg or libjpeg-turbo to build GTK, and their
build files may or may not generate pkg-config files for us. To make
things easier, we can make use of CMake's built-in support for finding
IJG libjpeg or libjpeg-turbo.
The CMake build files for libtiff may or may not generate pkg-config
files for us, so we can use Meson's CMake support to help us find
libtiff, as CMake has built-in support for finding libtiff.
Add a variable in meson.build that covers Visual Studio-like compilers,
so that we can use it to help us find depedencies using CMake rather
than via pkg-config, where applicable.
Change the existing use case for finding libpng accordingly.
We might have panels with controls in them where the window is running in
another process. The control could have a wrapper window which we would
see from this process. This can happen with the GtkFileChooserNative, but
any NSSavePanel in macOS 10.15+ is out of process (not just sandboxed
applications).
This significantly cleans up how we handle various move-resize, compute-
size, and configure (notification of changes) in the macOS GDK backend.
Originally when prototyping this backend, there were some bits that came
over from the quartz backend and some bits which did not. It got confusing
and so this makes an attempt to knock down all that technical debt.
It is much simpler now in that the GdkMacosSurface makes requests of the
GdkMacosWindow, and the GdkMacosWindow notifies the GdkMacosSurface of
changes that happen.
User resizes are delayed until the next compute-size so that we are much
closer to the layout phase, reducing chances for in-between frames.
This also improves the situation of leaving maximized state so that a
grab and drag feels like you'd expect on other platforms.
I removed the opacity hack we had in before, because that is all coming
out anyway and it's a bit obnoxious to maintain through the async flows
here.
This fixes GTK's NSWindow for toplevels so that they are allowed to enter
fullscreen. We were already handlign the state transitions from the
setStyleMask: halper, but we didn't previously tell the window we are
allowed to transition into that.
There is a bit of a mismatch here in that GTK doesn't have any such flag
that determines if a window is "allowed" by policy to enter fullscreen
since window managers on Linux are free to do that at will.
This makes it easier to figure out those values (which are mentioned in
the GtkApplication documentation) rather than working that out from the
way they're generated (or documented as being generated).
If we have GStreamer on macOS we likely have support for CGL to get an
OpenGL context we can use. This provides the missing pieces to get
accelerated video playback in gtk4-widget-factory working.
This more than halves the total runtime of this function since the
previous commit, from 8.36% to 4.02%, and is most likely memory
bandwidth limited on this specific board now.
I tried to do a SSE2 version as well, but couldn’t find any equivalent
of the LD4/ST4 ARM instruction.
On x86 on a Kaby Lake CPU, this makes it go from 6.63% of the total
execution time (loading some PNGs using the cairo backend) down to
3.20%.
On ARM on a Cortex-A7, on the same workload, this makes it go from 57%
to 8.36%.
We want our tracking area to be limited to the input region so that we
don't pass along events outside of them for the window. This improves the
chances we click-out of a popover with a large shadow.
This still doesn't let us pass-through clicks for large shadows on top-
level windows though.
We only should be asserting in static functions. Furthermore, this function
did not need to have GDK_BEGIN_MACOS_ALLOC_POOL as nothing is being
allocated there which would cause pooling to get used.
This needs to handle the boundary case where the value is exactly equal
to the edge of a rectangle (which gdk_rectangle_contains_point() does not
consider to be containing). However, if there is a monitor in the list
that is a better match, we still want to prefer it.
When using an external mouse on MacOS, the scrolling behavior is
reversed from the user's scrolling preference. Additionally, it is
noticeably sluggish.
This commit fixes both issues by negating the deltas and multiplying
them by 32 before constructing a new scroll event. 32 seems to be the
"traditional" scaling factor according to [Druid], but I'm not sure
where that value actually comes from. Regardless, scaling the deltas by
this amount makes scrolling feel a lot more responsive in the GTK demos.
Scrolling with a trackpad is not affected by either issue because it
triggers a different code path that uses more precise deltas, and
already negates them.
[Druid]: https://linebender.gitbook.io/linebender-graphics-wiki/mouse-wheel#external-mouse-wheel-vs-trackpad
We currently list everything as a dependencies, regardless of whether
it actually is; this is a source of confusion for users that read the
GTK documentation.
Gi-docgen has a new "related" key in the project configuration which
allows us to list libraries that are merely related to the namespace
we are documenting; the "dependencies" key is used to document the
actual namespace dependencies, now.
This was causing us to draw the same background content twice which is a
significant amount of bits to flip in the GPU for maximized windows,
especially twice.
This updates GtkPopover to use the new GtkNative abstraction for
reporting opaque regions of the window, in hopes that it can speed
up compositors for things like animated lists, menu transitions,
and more.
Fixes#4689
This switches to using the new GtkNative machinery for updating the
opaque region. Some amount of local calculation is still required for
determining when we should apply shadows, and this inherits what was
done previous for that.
Related #4689
