Don't place the insertion cursor render nodes in the
middle of the text nodes for all the text. This helps
the renderer batching the text draw calls together.
We only need this to render shapes and trapezoids, i.e. only when
falling back to cairo. Remove code to measure the layout and convert the
ink_rect to a graphene_rect_t from gtk_snapshot_append_layout() and do
it when drawing shapes and trapezoids instead.
We were doing more iter comparisons than necessary in the
inner loop of gtk_text_layout_snapshot(), in the presence
of a selection. Rewrite the code to compare line numbers
instead, which is faster than full iter comparisons.
When we invalidate a y_range using the common pattern of y==0 and
old_height==new_height, we are generally invalidating the entire buffer.
This short-circuits that case to just invalidate the buffer in a faster
and more complete form. The problem here appears to be that we can't
always calculate the ranges properly to invalidate because validation
has not run far enough.
GtkTextLayout is private now and therefore we can drop all of
the indirection through the class vtable. Instead, just call the
implementations directly and remove the unused vtable entries
for default signal handlers.
This changes gtk_text_buffer_insert_texture() to
gtk_text_buffer_insert_paintable() which is strictly more useful
(as textures are paintables). It also fixes the code to actually
support drawing the paintables (as well as tracking changes
to the paintables.
The only other visible mark that is in common use
besides insert and selection_bound is dnd_mark, and
we don't want it to blink or be affected by 'cursor'
visibility.
Therefore, cache not just the cursor positions, but
also whether they are insert or selection_bound,
and take that into account when rendering them.
We can avoid recreating a number of text nodes from render_para() on
sub-sequent runs if we cache the rendernode instead of just the
PangoLayout.
When used with GtkSourceMap, this can yield a ~7 FPS improvement during
smooth scrolling at the cost of some more memory.
This tries to estimate the number of visible rows in a textview based on
the default text size and then tunes the GtkTextLineDisplayCache to keep
3*n_rows entries in the cache.
This was found imperically to be near the right cache size. In most cases,
this is less than the number of items we cache now. However, in some cases,
such as the "overview map" from GtkSourceView, it allows us to reach a
higher value such as 1000+. This is needed to keep scrolling smooth on
the larger view sizes.
With this patch, a HiDPI system with a GtkSourceView and GtkSourceMap
from the GTK 4 port can perform smooth scrolling simultaneously.
We do not need to create a GtkTextIter to perform the comparison here as
that will require a number of validation steps that are extra work
compared to just discovering the GtkTextLine number directly.
This adds a GtkTextLineDisplayCache which can be used to cache a number
of GtkTextLineDisplay (and thus, PangoLayout) while displaying a view.
It uses a GSequence to track the position of the GtkTextLineDisplay
relative to each other, a MRU to cull the least recently used display,
and and a direct hashtable to lookup display by GtkTextLine.
We only cache lines that are to be displayed (!size_only). We may want to
either create a second collection of "size_only" lines to speed that up,
or determine that it is unnecessary (which is likely the case).
Don't insert text attributes if the font, or scale
or fallback did not actually change. This helps
Pango avoid excessive item breaks, which in turn
helps shaping to work across things like color
changes.
Related: https://gitlab.gnome.org/GNOME/pango/issues/28
This makes GtkTextLineDisplay use GRcBox instead of g_slice_*
directly. By using reference counting for this structure, we
can ensure that we hold an extra ref for one_display_cache as
well as caching additional GtkTextLineDisplay for the visible
range in the future.
This removes the use of GtkTextDisplay (a PangoRenderer) to use
the GskPangoRender which generates render nodes. Part of this means
improving the GskPangoRenderer to support the necessary features for
displaying a GtkTextView.
Primarily, this is a merging of GtkTextDisplay features into
GskPangoRender. Additionally, GtkTextDisplay was removed to allow for
gtk_text_layout_snapshot() to be implemented elsewhere.
This exists to exit early for invisible lines. It attempts to use the
LineDisplay’s direction to create a corresponding PangoLayout. However,
the dir is not yet set by this point, & the display was new0()d, so its
dir is always 0 == TEXT_DIR_NONE. Thus, we always create an LTR layout.
Whatever the original intent, this outcome seems to be OK, so let’s make
the code say what it means, rather than using a misleading conditional.
https://bugzilla.gnome.org/show_bug.cgi?id=779099
This affects a few apis, such as gtk_text_iter_get_pixbuf,
gtk_text_buffer_insert_pixbuf and GtkTextBuffer::insert-pixbuf,
which have all been replaced by texture equivalents.
Update all callers.
This patch makes that work using 1 of 2 options:
1. Add all missing enums to the switch statement
or
2. Cast the switch argument to a uint to avoid having to do that (mostly
for GdkEventType).
I even found a bug while doing that: clearing a GtkImage with a surface
did not notify thae surface property.
The reason for enabling this flag even though it is tedious at times is
that it is very useful when adding values to an enum, because it makes
GTK immediately warn about all the switch statements where this enum is
relevant.
And I expect changes to enums to be frequent during the GTK4 development
cycle.
