Most likely, the image for all glyphs will be the same atlas,
so check first before calling the add_image function, which
will loop over all images.
This matches what the pattern code does for glyph nodes.
The performance impact of this is hard to measure.
Do the glyph cache lookup in two steps: First find a cache for
the given font+scale, then look up the glyph+flags. Since
font+scale change much less frequently (in particular, they are
the same for all glyphs in a text node), it makes sense to keep
the result of the last lookup around and check if it still fits.
Here are changes in running widget-factory with no-vsync:
before after
gsk_gpu_device_lookup_glyph_image 1.43% 1.02%
g_hash_table_lookup 0.76% 0.43%
gsk_gpu_cached_glyph_equal 0.28% 0.21%
Create the scaled font on demand, only when we need to render a glyph,
and keep it around while processing the remaining glyphs in the text
node, rather than recreating it over and over.
This changes the approach we take to rendering glyphs in the
presence of a scale transform: Instead of scaling the extents
and rendering to an image surface with device scale, simply
create a scaled font and use it for extents and rendering.
This avoids clipping problems with scaling of extents in
the presence of hinting.
When we've handled a inhibit idle request via Wayland, there is
no need to call into the D-Bus inhibit api unless there's other
inhibit flags to handle.
Fixes: #6470
It turns out that the workaround in 7b380b2ffc was insufficient.
During initialization, we end up calling apply_monitor_changes()
while xdg_output is set, but xdg_output_geometry isn't. Be more
careful and prevent that from wreaking havoc with negative scales.
Fixes: #6472
Otherwise symbolic icons won't be recognized as such.
Currently, in apps like Icon Library / App Icon Preview. Trying to
render the generated on-fly symbolic icons, require caching them in a
directory that mimics an icon theme and updating the search path of the
default gtk::IconTheme. That is mostly because
Gtk.IconPaintable.new_for_file wouldn't set is-symbolic even if the
passed file is a symbolic icon.
This would allow us to remove all the hacks in our apps
unsigned char is promoted to int, which lacks the 32nd bit to
make 0xff << 24 work. Explicitly cast to unsigned int to make
it clear what we want to happen.
While the text data returned by the `get_contents`
function from the `GtkAccessibleTextInterface` does not
have to be NUL-terminated,
`gtk_accessible_text_get_contents` returns the
text contents as NUL-terminated UTF-8 data.
An empty string (returned as empty, i.e. size = 0,
but not NULL GBytes* data by `get_contents`) is valid, and
therefore also needs to be NUL-terminated, so do this.
Without this, e.g. querying the text of an empty paragraph
in the Gtk 4 variant of LibreOffice with the newly added
GtkAccessibleInterface implementation [1] gives an incorrect
result.
Previous sample use in Accerciser's IPython console:
In [24]: acc.queryText().getText(0, -1)
Out[24]: '[Invalid UTF-8]'
With this change in place, it now returns an empty
string as expected:
In [25]: acc.queryText().getText(0, -1)
Out[25]: ''
[1] https://git.libreoffice.org/core/commit/e268efd612d12ae9a459d6b9d0cb23220f025163
Multilanguage searching for GtkEmojiChooser
This makes the Emoji chooser search look for strings in both
the current locale (if available), and in English. Each resource
file now contains the locale+English data. To accommodate the
changed dataset and schema, the recent-emoji settings key has
been renamed to recently-used-emoji.
See merge request GNOME/gtk!6804
The text retrieved using `gtk_accessible_text_get_contents`
already contains only the character at the given offset,
and so the character is at index 0 in `str`, rather than at
the same offset again, so adjust this accordingly.
With this in place, querying the character in a
LibreOffice paragraph consisting of the text
"Hello world." now gives the expected results
with a pending LibreOffice change [1] to support
the new GtkAccessibleText interface:
In [1]: text = acc.queryText()
In [2]: text.getCharacterAtOffset(0)
Out[2]: 72
In [3]: text.getCharacterAtOffset(1)
Out[3]: 101
In [4]: text.getCharacterAtOffset(2)
Out[4]: 108
In [5]: text.getCharacterAtOffset(3)
Out[5]: 108
In [6]: text.getCharacterAtOffset(4)
Out[6]: 111
Previously, this would only work correctly
for an index of 0:
In [1]: text = acc.queryText()
In [2]: text.getCharacterAtOffset(0)
Out[2]: 72
In [3]: text.getCharacterAtOffset(1)
Out[3]: 0
In [4]: text.getCharacterAtOffset(2)
Out[4]: 0
In [5]: text.getCharacterAtOffset(3)
Out[5]: 0
In [6]: text.getCharacterAtOffset(4)
Out[6]: 0
[1] https://gerrit.libreoffice.org/c/core/+/163733
This command can be used to compare the rendering of a node
to a reference image. It can also be used to compare the
renderings of two nodes, or to compare two images.
