For some reason modules/input adds the C code that is generated by
wayland-scanner to EXTRA_DIST. This results in a race where depending
on the timestamps of the tarball and the timestamp of the system
wayland-protocols either the generated source in the tarball or a
regenerated source will be used.
This doesn't actually impact the code generated, but it does break
reproducible builds as the list of source files changes.
When making changes above the current visible region, we might need to
invalidate the pixelcache as the Y positions will no longer match. This
usually is not needed because changes are made interactively and are made
onscreen.
Other cases, though, can include an application changing the first line
of the buffer automatically. We lose the ability to pixelcache well in
this scenario, but that is unlikely an issue since rapid Y geometry resize
or scrolling is less likely to be occuring. For situations where this is
an issue, you can avoid removing the \n from the buffer so line heights
are uneffected.
Fixes#2882
The Quartz Window Manager adds to the Windows menu all NSWindows with
titles. Since we assign a default title to all windows that produced a
rather cluttered Windows menu containing among other things dialogs.
Setting aside that dialogs don't belong in the Windows menu, if
a dialog was hidden for reuse instead of destroyed it would persist in
the Windows menu and if clicked there would show, but because it wasn't
running wouldn't respond to events and so couldn't be hidden again and
would remain on top of its parent window.
Ref: https://bugs.gnucash.org/show_bug.cgi?id=797807
This patch implements the openFiles delegate which is required
to open files which are associated with an application via the
Finder or via open on the command line. The patch has been
proposed by jessevdk@gmail.com.
See: https://gitlab.gnome.org/GNOME/gtk/-/issues/463
I tested the patch with the GNU pspp application on MacOS with
the quartz backend.
gtk_file_chooser_get_filter Make gtk_file_chooser_get_filter work for the non-portal GtkFileChooserNative (issue #1820)
See merge request GNOME/gtk!1959
Fix scheduling of the frame clock when we don't receive "frame drawn"
messages from the compositor.
If we received "frame drawn" events recently, then the "smooth frame
time" would be in sync with the vsync time. When we don't receive frame
drawn events, the "smooth frame time" is simply incremented by constant
multiples of the refresh interval. In both cases we can use this smooth
time as the basis for scheduling the next clock cycle.
By only using the "smooth frame time" as a basis we also benefit from
more consistent scheduling cadence. If, for example, we got "frame
drawn" events, then didn't receive them for a few frames, we would still
be in sync when we start receiving these events again.
When an animation is started while the application is idle, that often
happens as a result of some external event. This can be an input event,
an expired timer, data arriving over the network etc. The result is that
the first animation clock cycle could be scheduled at some random time,
as opposed to follow up cycles which are usually scheduled right after a
vsync.
Since the frame time we report to the application is correlated to the
time when the frame clock was scheduled to run, this can result in
uneven times reported in the first few animation frames. In order to fix
that, we measure the phase of the first clock cycle - i.e. the offset
between the first cycle and the preceding vsync. Once we start receiving
"frame drawn" signals, the cadence of the frame clock scheduling becomes
tied to the vsync. In order to maintain the regularity of the reported
frame times, we adjust subsequent reported frame times with the
aforementioned phase.
`gtk_builder_get_parameters()` is a hot path, being called twice for
each object in each UI file in an application. The majority of objects
have ≤ 8 properties, which are each filtered into either `parameters` or
`filtered_parameters`.
Unfortunately, both of those arrays are created as empty `GArray`s, and
adding 8 elements to an empty `GArray` hits the worst possible case of
reallocating and `memcpy()`ing the array 3 times. As the array size is
doubled with each reallocation, the cost is not particularly well
amortised when the array size is small.
From the `ObjectInfo`, we actually know how many properties there are in
total, so just allocate the arrays at the right size to begin with.
This saves 7% of the instruction cycles needed to start up
gnome-software to the point where it’s showing its main window,
according to callgrind. gnome-software is making around 5500 calls to
`gtk_builder_get_parameters()`.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
