When surface depth switches from non-high-depth to high-depth (or vice
versa) the current surface has to be destroyed before a new one can be
created for this window. eglDestroySurface however was getting passed a
GdkDisplay, rather than the EGLDisplay it expects. As a result the old
surface did not get destroyed and the new surface could not be created
causing rendering to freeze.
Fixes: https://gitlab.gnome.org/GNOME/gtk/-/issues/4773
If using the opacity CSS property the renderer cannot optimize these
handles without the use of offscreens due to the use of both a border
and rgb render node.
Instead, we can apply the alpha to the color values and get the same
effect in a way that the GL renderer can optimize without the use of
offscreen textures for a sizeable reduction in runtime overhead.
The pixel distance could be small enough between tick() calls that
this kind of checks might potentially become a problem. Rely only on
the calculated velocity to trigger the STOPPED phase, and use a lower
threshold to avoid cutting the animation too early.
Related: https://gitlab.gnome.org/GNOME/gtk/-/issues/4725
In order to properly accumulate scroll velocities, we need to keep
the kinetic scroll helpers after we have possibly stopped them
in the process of initiating a further scroll flick.
So, instead of stopping (and destroying) those helpers on scroll-begin,
keep them until the next scroll-end if a scroll was initiated before
kinetic scroll finished. This way we can fetch the last velocity when
calculating the extra kick.
In order to ensure the helpers don't live beyond what it is expected,
we now also remove them after a finished hold event.
Fixes the accumulation of scrolling velocity on consecutive scroll
sequences.
Do not depend on the kinetic scroll helpers existing or not before
exiting the animation, as we may want to keep those a little bit
longer after stopped.
We may want to fetch the last velocity obtained, even though we
preemptively called stop() on a kinetic scroll helper. Keep this
velocity so it can be queried later on.
On the "scroll" signal, the widget uses
gtk_event_controller_scroll_get_unit() to get the
scroll unit.
When the unit is GDK_SCROLL_UNIT_WHEEL, the
behavior is unchanged: the widget scrolls a
certain number of pixels at each wheel detent
click. This number of pixels is determined by the
window dimensions in get_wheel_detent_scroll_step().
When the delta unit is GDK_SCROLL_UNIT_SURFACE, the
widget directly adds the delta to the number of
scrolled pixels no matter the window dimensions.
Add a new GdkScrollUnit enum that represent the
unit of scroll deltas provided by GdkScrollEvent.
The unit is accessible through
gdk_scroll_event_get_unit().
This moves a lot of the texture atlas control out of the driver and into
the various texture libraries through their base GskGLTextureLibrary class.
Additionally, this gives more control to libraries on allocating which can
be necessary for some tooling such as future Glyphy integration.
As part of this, the 1x1 pixel initialization is moved to the Glyph library
which is the only place where it is actually needed.
The compact vfunc now is responsible for compaction and it allows for us
to iterate the atlas hashtable a single time instead of twice as we were
doing previously.
The init_atlas vfunc is used to do per-library initialization such as
adding a 1x1 pixel in the Glyph cache used for coloring lines.
The allocate vfunc purely allocates but does no upload. This can be useful
for situations where a library wants to reuse the allocator from the
base class but does not want to actually insert a key/value entry. The
glyph library uses this for it's 1x1 pixel.
In the future, we will also likely want to decouple the rectangle packing
implementation from the atlas structure, or at least move it into a union
so that we do not allocate unused memory for alternate allocators.
This removes the sharing of atlases across various texture libraries. Doing
so is necessary so that atlases can have different semantics for how they
allocate within the texture as well as potentially allowing for different
formats of texture data.
For example, in the future we might store non-pixel data in the textures
such as Glyphy or even keep glyphs with color content separate from glyphs
which do not and can use alpha channel only.
This allows the gskglprograms.defs a bit more control over how a shader
will get generated and if it needs to combine sources. Currently, none of
the built-in shaders do that, but upcoming shaders which come from external
libraries will need the ability to inject additional sources in-between
layers.
If the max_entry_size is zero, then assume we can add anything to the
atlas. This allows for situations where we might be uploading an arc list
to the atlas instead of pixel data for GPU font rendering.
