[vim/gvim] Some work in progress on optimizing gui_gtk2_draw_string

[Dusan Popovic]

I am doing some work on gvim that will hopefully result in further
optimization in rendering and proper usage of ligatures. Since I just
opened vim code last night, there is number of building blocks I have to
find. Maybe they already exist in gvim, maybe we need to fall back to
Pango or some other solution... I don't know yet. Please take a look
below and tell me what building blocks we already have.


So having char_u * containing "first 😃😃😃 second" (three smileys
between two words, separated by spaces),

Such string having hex representation:

f i r s t _ [ ] [ ] [ ] _ s e c o n d
66 69 72 73 74 20 f0 9f 98 83 f0 9f 98 83 f0 9f 98 83 20 73 65 63 6f 6e 64

I am looking for a most efficient way to split that into ascii and
non-ascii parts, ideally something like:

1: f i r s t _
66 69 72 73 74 20

2: [ ] [ ] [ ]
f0 9f 98 83 f0 9f 98 83 f0 9f 98 83

3: _ s e c o n d
20 73 65 63 6f 6e 64

Is there something useful and super efficient (this needs to run close
to gui_gtk2_draw_string) that will allow me to split char_u* into
logical ascii/non-ascii parts? Something in mbyte.c maybe?

Alternatively anything that can take *s and tell me the length of next
char/segment will be fine too, I can build actual split strings myself
then.

Reason for asking this is that we are falling back to "goto not_ascii;"
way too soon and in too many cases, for anything that is not plain ascii
or bold or italic. Proper additional splitting will allow us to feed
only specific segments to Pango and use gui.ascii_glyphs in more cases,
thus optimizing output. This is also stepping stone to having proper
ligatures in gvim. So how do I split the string in a super efficient
way?

[Dusan Popovic]

On 28/09/21, Dusan Popovic wrote:
> So how do I split the string in a super efficient way?

Already solved in
https://github.com/dusanx/vim/commit/a00791cd3c0df7d921bb4188df1c165de04961d3
and should be rock solid (wikipedia + stackowerflow as sources), however
if anybody spots any error or there is a better way I'd like to hear
about that.

[Bram Moolenaar]

Dusan Popovic wrote:

> I am doing some work on gvim that will hopefully result in further
> optimization in rendering and proper usage of ligatures. Since I just
> opened vim code last night, there is number of building blocks I have to
> find. Maybe they already exist in gvim, maybe we need to fall back to
> Pango or some other solution... I don't know yet. Please take a look
> below and tell me what building blocks we already have.

I haven't looked at this code recently, and I didn't write it (perhaps
some fixes over time), but I thought the idea was that a lot of text is
ASCII and we wanted to make sure that can be drawn quickly. Any
non-ASCII might require special handling (especially composing
characters).

If you now also use the special handling for some ASCII characters,
perhaps the special casing can just be skipped? So instead of
specifying exactly what ASCII characters should be given the special
handling, just make an on/off switch. What would the performance impact
be? Perhaps if letters and digits can still be handled like ASCII now
the speedup is noticeable.

General rule: don't optimize code for speed unless you can measure the
improvement.

--
hundred-and-one symptoms of being an internet addict:
75. You start wondering whether you could actually upgrade your brain
with a Pentium Pro microprocessor 80. The upgrade works just fine.

/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

[Dusan Popovic]

On 28/09/21, Bram Moolenaar wrote:
> If you now also use the special handling for some ASCII characters,
> perhaps the special casing can just be skipped?

Current state of affairs in gvim:

- glyphs are prerendered at ascii_glyph_table_init
- non-bold non-italic ascii < 128 is rendered with glyphs
- bold, italic, string with single >128 char, all falls down to Pango
- big string ready to use glyphs but having single complex utf-8 char
will fall trough to be rendered with Pango.

Pango is not optimal:

- Not measured but very visible: In my c++ projects at work color scheme
renders renders function names in bold, which fall down to Pango. When
I quickly scroll trough region with 'more' bold content, scroll
becomes erratic, with more normal text it becomes smoother.

Current patch I am working on
(https://github.com/dusanx/vim/commit/a00791cd3c0df7d921bb4188df1c165de04961d3)
additionally splits strings into clear ascii/everything else parts,
which then go trough glyphs or Pango. Result is rendering with Pango
only what we can't avoid and using glyphs for everything else. Almost a
side effect is proper ligatures support.

When that is done, in next PR, I intend to introduce cache for bold and
italic glyphs, same as we do for normal text. There is no need to treat
bold differently and use Pango for that.

In short using Pango as little as possible should be valid gvim
optimization. Using Pango for everything because of few ligatures and
emojis should be avoided because of the visible speed penalty. However
if you see some obstacle for this plan please let me know.

[Bram Moolenaar]

Sounds good.

I would think that italic isn't used much, but if it's just another
entry with the same code we might as well cache that too.

--
hundred-and-one symptoms of being an internet addict:

89. In addition to your e-mail address being on your business
cards you even have your own domain.