[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: MPS: face-cache
From: |
Gerd Möllmann |
Subject: |
Re: MPS: face-cache |
Date: |
Sun, 28 Apr 2024 10:05:03 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
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...
- Re: MPS: face-cache, (continued)
- Re: MPS: face-cache, Helmut Eller, 2024/04/28
- Re: MPS: face-cache, Gerd Möllmann, 2024/04/28
- Re: MPS: face-cache, Helmut Eller, 2024/04/28
- Re: MPS: face-cache, Gerd Möllmann, 2024/04/28
- Re: MPS: face-cache, Gerd Möllmann, 2024/04/28
- Re: MPS: face-cache, Gerd Möllmann, 2024/04/28
- Re: MPS: face-cache, Eli Zaretskii, 2024/04/28
- Re: MPS: face-cache, Gerd Möllmann, 2024/04/28
- Re: MPS: face-cache, Eli Zaretskii, 2024/04/28
- Re: MPS: face-cache,
Gerd Möllmann <=
- Re: MPS: face-cache, Eli Zaretskii, 2024/04/28
- Re: MPS: face-cache, Gerd Möllmann, 2024/04/28
- Re: MPS: face-cache, Po Lu, 2024/04/28
- Re: MPS: face-cache, Eli Zaretskii, 2024/04/28
- Re: MPS: face-cache, Po Lu, 2024/04/28
- Re: MPS: face-cache, Gerd Möllmann, 2024/04/28
- Re: MPS: face-cache, Gerd Möllmann, 2024/04/28
- Re: MPS: face-cache, Po Lu, 2024/04/28
- Re: MPS: face-cache, Gerd Möllmann, 2024/04/28
- Re: MPS: face-cache, Gerd Möllmann, 2024/04/28