Instead of going through an ancillary script to strip away the
`WL_EXPORT` annotation from the generated code, we should bump up the
required version of Wayland, and use the `private-code` argument for
wayland-scanner, which does the right thing for us.
There where some problems (??) with ccache not detecting changes during meson
checks. Setting CCACHE_DISABLE during the meson execution makes ccache not use
the cache and pass things directly to the compiler.
Instead of connecting to / disconnecting from the frame clock, do it
inside the vfuncs next to changing the priv->realized boolean.
This removes a race between those 2 cases that could cause child
widgets' unrealize handlers to reconnect this widget to the frame clock
because it was still marked as realize when the widget had already
disconnected from the frame clock.
Fixes#168
But in turn, also allow it to work on widgets with their own surface.
This way, we can chain up from everywhere and won't have to export
gtk_widget_set_realized().
When using strncpy() with a buffer we need to account for the
terminating NUL character. GCC 8 started warning when using PPD_MAX_NAME
as the buffer length for strncpy() because the buffer we're copying into
has the same length — which means that the terminating NUL may be
skipped if the source string has a length of PPD_MAX_NAME.
The appropriate way to handle the case where we're copying a source with
a length bigger than of PPD_MAX_NAME is, as reported in the strncpy()
documentation, to copy `PPD_MAX_NAME - 1` bytes, and explicitly NUL
terminate the destination buffer. This has the additional benefit of
avoiding the compiler warning.
* Previous commit had misleading info. The code was
added to begin_paint() instead of end_paint(). Though
that did not affect its performance in any visible way.
* Company advised to move the code to an "after_paint" signal
handler, so that it works on all renderers, not just Cairo.
This change caused high fluctuation in FPS values in fishbowl
when it is put in a situation where it cannot achieve 60fps
(such as using Cairo renderer at ultra-high resolution).
This seems to be deliberate and not a bug.
There is no easily apparent way of being notified when frame updates
happene exactly, so we just query frame info at the end of each paint.
If we query too often (faster than DWM refresh rate), we just get
the same values twice in a row, but that is, hopefully, highly unlikely.
