Subject: bug#39133: 28.0.50; Emacs slowdown on special char

From: Robert Pluim <[email-masked]>
Date: Mon, 02 Mar 2020 08:40:02 +0100

>>>>> On Fri, 24 Jan 2020 17:52:12 +0200, Eli Zaretskii <[email-masked]> said:

    >> From: Robert Pluim <[email-masked]>
    >> Cc: [email-masked],  [email-masked],
    >> [email-masked],  [email-masked]
    >> Date: Fri, 24 Jan 2020 16:41:40 +0100
    >> 
    >> >>>>> On Fri, 24 Jan 2020 14:50:10 +0100, Robert Pluim <[email-masked]> said:
    Robert> Yes, I worked that out. A simple crash, for once :-)
    >> 
    >> >From 667f47abecc13e8a47181f338e727d95e57a6354 Mon Sep 17 00:00:00 2001
    >> From: Robert Pluim <[email-masked]>
    >> Date: Fri, 24 Jan 2020 14:11:44 +0100
    >> Subject: [PATCH] Don't attempt to cache glyph metrics for FONT_INVALID_CODE
    >> 
    >> This was causing massive slowdown in redisplay when eg #xfe0f
    >> (VARIATION SELECTOR-16) was present, as the cache ended up very large,
    >> unused, and being recreated on every call to font_fill_lglyph_metrics
    >> (Bug#39133).
    >> 
    >> * src/composite.c (fill_gstring_body): Hoist FONT_OBJECT_P check out
    >> of loop.  Calculate glyph code and check for FONT_INVALID_CODE before
    >> calling font_fill_lglyph_metrics.  Pass glyph code to it.
    >> 
    >> * src/font.c (font_fill_lglyph_metrics): Add code parameter, move
    >> glyph code calculation up the call stack into fill_gstring_body.
    >> 
    >> * src/font.h: Adjust font_fill_lglyph_metrics prototype.

    Eli> Thanks.

So Mike Fabian has tested this, and it works for him. Which branch
would you like me to push this to?

Robert