bug#11822: 24.1; emacsclient terminal mode captures escape characters as text

[Ken Raeburn <raeburn@permabit.com>]

On Aug 10, 2012, at 02:16, Eli Zaretskii wrote:
> Normally, the frame's face cache is not removed during redisplay of
> frame's windows, so you get one call per frame.  For new frames, the
> cache is empty, so you get 3 calls for each window on the new frame,
> which are: the frame's selected window, the menu bar, and the tool bar
> (the last two are displayed in a special kinds of window).  For
> example, the backtrace above comes from displaying the menu bar.

Ah, that's interesting.  It's especially interesting considering I have menu bar and tool bar displays turned off.  The one frame (X11 window) I have on the remote display is subdivided into four Emacs windows (top vs bottom, then each of those split into left and right).  And there's the minibuffer, of course.  Currently three of those four windows have header lines, but there is no tool bar or menu bar.

> 
>> But either way, we get into the display code and it thinks it's got to 
>> do the color/face setup all over again for the remote display.
> 
> If the face cache is empty, what else can it do?

I haven't really looked at the redisplay code much, but shouldn't a cache be, I don't know, caching this stuff it keeps looking up over and over?  According to the code you quoted, it's a "face cache", and all I see is color-processing calls, but if we're not building faces, why do we need the color processing, and if we are building them, why aren't we caching them?

Oh, hmm… the code you quoted ensures that the indicated frame has a face cache, and conditionally calls recompute_basic_faces; that function checks that there is a face cache, and if so, calls clear_face_cache and then realize_basic_faces.  But clear_face_cache clears caches of all frames.  So if I understand correctly, if that function you quoted (init_iterator) is given a frame with no cache (which I assume is the state a new frame is in?), or if the cache "used" flag is clear, it'll wipe out all cached faces from all frames, so the higher-level iteration over all the frames (or windows?) will have to rebuild the faces, even if they had indeed been cached.  Is that correct?

Is there a reason recompute_basic_faces can't just clear the cache for its own frame and leave the others alone?

Ken