bug#233: Analysis of redisplay performance on Windows

bug#233: Analysis of redisplay performance on Windows

[Jason Rumney]

The redisplay performance problems on Windows seem to be mostly caused
by the left_overwriting and right_overwriting functions. These functions
analyse all glyphs, one by one, before and after (respectively) the
current glyph string on the same row to see if the glyphs overlap the
current glyph string.

To determine the overlap for each glyph, it is necessary to encode it
into a glyph code point in the font used to display it, then measure its
text extents.  Even with caching of the text extents, the Windows code
is still especially slow here because of the encoding to glyph code points.

Currently we cache glyph code points at the glyph_string level. Perhaps
caching them at the glyph row level would help, as we could then reuse
them after we have finished with the glyph string. Alternatively we
could keep all the glyph strings for the row until we are finished so we
could use glyph code points and other information from there. This might
reduce the number of iterations we need to find the left and right
overwriting glyphs, since we can check the glyph strings for overlaps
first, and only check the glyphs inside glyph strings that overlap.

There may also be a problem with the setting of
row->contains_overlapping_glyphs_p on Windows. The above functions
should only be called when that is set, but after inserting debugging
code I can see them being called frequently even when using fonts that
contain no overlapping glyphs (confirmed by further debugging code in
w32font_text_metrics).

bug#233: Analysis of redisplay performance on Windows

[Lennart Borgman (gmail)]

Jason Rumney wrote:
> The redisplay performance problems on Windows seem to be mostly caused
> by the left_overwriting and right_overwriting functions. These functions
> analyse all glyphs, one by one, before and after (respectively) the
> current glyph string on the same row to see if the glyphs overlap the
> current glyph string.
> 
> To determine the overlap for each glyph, it is necessary to encode it
> into a glyph code point in the font used to display it, then measure its
> text extents.  Even with caching of the text extents, the Windows code
> is still especially slow here because of the encoding to glyph code points.
> 
> Currently we cache glyph code points at the glyph_string level. Perhaps
> caching them at the glyph row level would help, as we could then reuse
> them after we have finished with the glyph string. Alternatively we
> could keep all the glyph strings for the row until we are finished so we
> could use glyph code points and other information from there. This might
> reduce the number of iterations we need to find the left and right
> overwriting glyphs, since we can check the glyph strings for overlaps
> first, and only check the glyphs inside glyph strings that overlap.
> 
> There may also be a problem with the setting of
> row->contains_overlapping_glyphs_p on Windows. The above functions
> should only be called when that is set, but after inserting debugging
> code I can see them being called frequently even when using fonts that
> contain no overlapping glyphs (confirmed by further debugging code in
> w32font_text_metrics).


Is this handled differently on GNU/Linux?