Re: Display performance degradation

[Kenichi Handa <handa@m17n.org>]

In article <wlljgzwu1c.wl%mituharu@math.s.chiba-u.ac.jp>, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:

> While I was looking at font caching code, I found a part that seems to
> be wrong, though it is not directly related to the original
> performance issue.

> Fclear_font_cache (in src/font.c):

>   4484		    val = XCDR (cache);
>   4485		    while (! NILP (val)
>   4486			   && ! EQ (XCAR (XCAR (val)), driver_list->driver->type))
>   4487		      val = XCDR (val);
>   4488		    font_assert (! NILP (val));
>   4489		    val = XCDR (XCAR (val));
>   4490		    if (XINT (XCAR (val)) == 0)
>   4491		      {
>   4492			font_clear_cache (f, XCAR (val), driver_list->driver);
>   4493			XSETCDR (cache, XCDR (val));
>   4494		      }
>   4495		  }

> At line 4490, XCAR (val) is expected to be of type Lisp integer.  But
> it is also passed to font_clear_cache at line 4492, which seems to
> expect the value of `val' as of line 4488 rather than the one assigned
> at line 4489.

Oops, Fclear_font_cache is a funciton I made for debugging,
but I have forgotten to put it within #ifdef FONT_DEBUG
... #endif, and also forgotten to adjsut it for the other
changes.

In article <m2eimrjnaf.fsf@igel.home>, Andreas Schwab <schwab@linux-m68k.org> writes:
> If the condition is ever true then Emacs crashes.  I've checked in a
> fix.

Thank you!

> But then, I don't think this function is ever more than a no-op
> anyway, since as soon as NUM-FRAMES becomes zero the cache is cleared
> automatically anyway.

Right, so it exists just for debugging.  But, I've just
found that the new file font-setting.el calls it now.  Ummm,
I'm not sure it works while a frame is alive.  I'll check
the code again.

---
Kenichi Handa
handa@m17n.org