Re: MPS: face-cache

["Gerd Möllmann" <gerd.moellmann@gmail.com>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> Cc: eller.helmut@gmail.com,  emacs-devel@gnu.org
>> Date: Sun, 28 Apr 2024 09:38:49 +0200
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> >> Someone knows something about this in struct frame?
>> >> 
>> >>   /* List of font-drivers available on the frame.  */
>> >>   struct font_driver_list *font_driver_list;
>> >
>> > It's a list of C structs, AFAICT.
>> 
>> Yes, looks like an interface, like the redisplay one.
>> 
>> struct font_driver
>> {
>>   /* Symbol indicating the type of the font-driver.  */
>>   Lisp_Object type;
>> 
>>   /* True iff the font's foundry, family, and adstyle names are case
>>      sensitive.  */
>>   bool case_sensitive;
>> 
>>   /* Return a cache of font-entities on frame F.  The cache must be a
>>      cons whose cdr part is the actual cache area.  */
>>   Lisp_Object (*get_cache) (struct frame *f);
>>   ...
>> 
>> So, somewhere is a cache, that's interesting. Where is it?
>
> It's in dpyinfo:
>
>   Lisp_Object
>   xfont_get_cache (struct frame *f)
>   {
>     Display_Info *dpyinfo = FRAME_DISPLAY_INFO (f);
>
>     return (dpyinfo->name_list_element);
>   }
>
> That name_list_element is the cache, of this form:
>
>    (DRIVER-TYPE NUM-FRAMES FONT-CACHE-DATA ...)
>
> On w32, dpyinfo is just a single global variable, so I protected the
> cache with staticpro.  But on platforms that support several displays
> in the same session, something else should be done to protect the
> cache for each instance of dpyinfo.

Thansk.

>
>> >> Looks to me that the font objecz could come from there.
>> >
>> > Can you tell how that could happen, with pointers to the code?
>> 
>> Oh, that's a bit difficult. I went frames up, read the code to
>> understand where the font object might come from. Then in functions
>> called fromt here, and landed in something retrieving Lisp_Objects from
>> these drivers. One can probably find that that by looking where the
>> frame's driver list is used.
>
> I looked, but couldn't find it.  All I see is that the driver's
> _type_ (a symbol) is used in font objects.  Otherwise, what I see is
> that we invoke driver's methods, like 'list', 'match', and 'has_char',
> but do not use the driver struct itself in dealing with fonts.

Eglot/clangd shows me it's used in font.c, for example

Lisp_Object
font_list_entities (struct frame *f, Lisp_Object spec)
{
  struct font_driver_list *driver_list = f->font_driver_list;

Not sure, but I think that's also one function is landed in when reading...