Re: Display performance degradation

[Kenichi Handa]

In article <address@hidden>, YAMAMOTO Mitsuharu <address@hidden> 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 <address@hidden>, Andreas Schwab <address@hidden> 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
address@hidden