bug#233: Analysis of redisplay performance on Windows

["Lennart Borgman (gmail)" <lennart.borgman@gmail.com>]

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?