Re: scratch/igc: Implications of MPS being asynchronous

[Pip Cet]

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

> Pip Cet <pipcet@protonmail.com> writes:
>
>>> Something like that, yes. Or maybe just clear the font caches completely
>>> when some criterion is met? Time, size, something else, no idea.
>>
>> That's what I meant: we use a dummy sentinel to detect a GC cycle, then
>> we trigger font cache compaction and re-enable GC cycle detection
>> afterwards.  We might want to add an additional delay or a flag se we
>> don't actually do anything in compact_font_caches if we know there
>> hasn't been a change.
>
> I think I understood what you mean.

Oh.  I misunderstood what you mean, then.

> What I meant is something completely independent of GC. For example:
>
> - Run a function every N seconds which completely clears a font cache when
>   it has more than M entries. Or deletes all entries not having been
>   used for O seconds, or whatever.
>
> - Or on cache use: When looking up a cache entry, when say there are >N
>   entries, delete the entries that haven't been used for the longest
>   time.
>
> Or other criteria like that, but without involving GC.

I think the main question is whether the font cache can be compacted by
ordinary code, or whether it needs to use MPS weak objects with all
their problems.  This depends on the font code and I need to study it:
there's no way to do things as precisely as the old GC does.

The old GC keeps a font cache entry alive if one of the font-entity
values is still reachable, and I don't understand why: there's no way to
go back to the cache entry or the font spec from the entity, is there?

To put it bluntly: if we unconditionally call clear-font-cache a lot,
will we leak memory?  If so, the function shouldn't be exposed to Lisp.
Otherwise, let's just do that every seventh GC or for any GC if it's
been an hour.

I see some minor flickering here, barely noticeable.  Could you let me
know if this issue is so much worse on other systems that we might have
to think about it?

(These specific values are very important and must not be changed in any
way whatsoever, since it's really important that avoidable minor
flickering be limited to the Sabbath GC or once per hour ;-) ).

(And is it really correct that the default behavior on Windows is never
to compact the font caches at all?  Is there some arrangement to run
clear-font-cache from a timer, or something?)

IOW, while I think there may be weak structures which would require a
complicated approach, I don't think this is one of those cases.  Worst
case, whatever design decision resulted in flickering on what I thought
was a double/triple buffered screen may have to be revisited.
(Definitely not by me, though; my eyesight isn't great (you may have
noticed extra typos lately), I'd have to be a daily user to be sure it's
an improvement, and I use X so cannot use PGTK (yet), but fixing this in
the mixed GTK/X primitives maze is most likely beyond me.  Switching to
Wayland in any way is an unnegotiable "no".)

Pip