The naming of pointers to GdkWaylandDisplay's were inconsistent.
Running the following commands in gtk+/gdk/wayland illustrate the
inconsistency:
$ grep -r '\<display_wayland\>' *.[ch] | wc -l
195
$ grep -r '\<wayland_display\>' *.[ch] | wc -l
81
This patch renames all occurrences of "wayland_display" to
"display_wayland". This is also consistent with naming in the X11
backend. A couple of whitespace changes were done as well in places
where the rename was already done, that added line breaks to long lines
that stood out.
https://bugzilla.gnome.org/show_bug.cgi?id=765474
Generate .pc files for the package, so that it would be easier for
building introspection for packages that depend on GTK+. Also split
PythonPath into PythonPath and PythonPathX64 to facilitate the build of
introspection files, which need to have Python that is built with the
same ac=rchitecture where GTK+ is built.
Clean up the formatting and spacing a bit.
When synthesizing keyboard repeat, we can potentially drift further from
the mark depending on the timing of the frame callback and how long it
took to deliver the event.
This patch attempts to reduce this by tracking from a stable epoch the
time of our next keyboard repeat.
https://bugzilla.gnome.org/show_bug.cgi?id=765567
There are various functions to access links based on their index for
a11y. We can spare quite a few lines of code by just using
g_list_nth_data instead of iterating over the list ourselves.
https://bugzilla.gnome.org/show_bug.cgi?id=765496
We perform lots of gadget allocations that require allocating a
GtkBuiltinIcon. One notable example is the scrollbar for a scrolled
window.
In the process of doing this, we often calculate baseline information that
isn't necessary. With how much this code path gets exercised, its worth
catching the result for the common case, which is that the font-description
has not changed and we are using the default language the application
was started with.
This simply caches the previous result and verifies that we can reuse it
with pango_font_description_hash() and a simple language check.
Numbers below are scrolling through a textview with GDK_KEY_Down.
Before:
SELF CUMULATIVE FUNCTION
[ 0.08%] [ 9.26%] gtk_builtin_icon_get_preferred_size
[ 0.01%] [ 8.82%] pango_context_get_metrics
[ 0.02%] [ 0.16%] gtk_widget_get_pango_context
[ 0.06%] [ 0.06%] pango_context_get_language
[ 0.01%] [ 0.02%] g_type_check_instance_cast
[ 0.02%] [ 0.02%] strlen
[ 0.02%] [ 0.02%] pango_context_get_font_description
[ 0.02%] [ 0.02%] g_list_foreach
[ 0.01%] [ 0.01%] gtk_css_style_get_value
[ 0.01%] [ 0.01%] itemize_with_font
[ 0.01%] [ 0.01%] pango_context_get_type
[ 0.01%] [ 0.01%] get_base_metrics
[ 0.00%] [ 0.01%] pango_font_metrics_unref
[ 0.01%] [ 0.01%] g_list_free
[ 0.01%] [ 0.01%] gtk_builtin_icon_get_type
After:
SELF CUMULATIVE FUNCTION
[ 0.08%] [ 0.18%] gtk_builtin_icon_get_preferred_size
[ 0.02%] [ 0.02%] pango_font_description_hash
[ 0.00%] [ 0.02%] gtk_widget_get_pango_context
[ 0.00%] [ 0.02%] g_object_get_qdata
[ 0.00%] [ 0.02%] g_datalist_id_get_data
[ 0.02%] [ 0.02%] gtk_builtin_icon_get_type
[ 0.01%] [ 0.01%] pango_context_get_font_description
[ 0.00%] [ 0.01%] - - kernel - -
[ 0.01%] [ 0.01%] pango_context_get_language
[ 0.00%] [ 0.01%] gtk_css_style_get_value
[ 0.00%] [ 0.01%] gtk_css_gadget_get_style
https://bugzilla.gnome.org/show_bug.cgi?id=765486
This allows us to decide when the R and B color channels should be
flipped with a much better granularity.
For instance, when using GLX_EXT_texture_from_pixmap to create a GL
texture from a surface we don't need to swap the R and B channels, as
the internal representation of the texture data will already have the
appropriate colors.
We also don't need to flip color channels when blitting from a texture.
Cairo surfaces are in BGRA format, but we upload them as RGBA buffers on
GLES; this means that the R and B channels are flipped in the texture
data.
Instead of doing a costly channel flip before putting them on the GPU,
we can flip the values inside the GLSL shader we use specifically for
GLES.
We cannot use GL_BGRA and GL_UNSIGNED_INT_8_8_8_8_REV when reading back
from the frame buffer in the software fallback path, as they do not
exist on OpenGL ES.
This will make the slow path a bit slower, because of the implicit
format conversion.
When uploading a Cairo image surface to a GL texture we cannot use
GL_BGRA and GL_UNSIGNED_INT_8_8_8_8_REV on OpenGL ES, as they do not
exist in the core spec.
On some platforms we can ask the GL context machinery to create a GLES
context, instead of a GL one.
In order to ask for a GLES context at GdkGLContext realization time, we
use a bit field like we do for forward compatible, or debug contexts.
The 'use-es' bit also changes the way we select a default version,
because OpenGL and OpenGLES versions differ.
https://bugzilla.gnome.org/show_bug.cgi?id=743746
When decelerating the kinetic scroll, we can get into a position where it
looks like we are stuttering. This happens because the amount we move is
so little that it takes multiple frames to make forward progress by one
pixel.
This prevents that by detecting when we have reached the slow stutter of
the deceleration and simply stops the deceleration phase immediately.
https://bugzilla.gnome.org/show_bug.cgi?id=765493
