From: Eli Zaretskii <eliz@gnu.org>
To: Visuwesh <visuweshm@gmail.com>
Cc: luangruo@yahoo.com, 73752@debbugs.gnu.org, xuan@xlk.me
Subject: bug#73752: 29.4; Ligatures are randomly rendered with extra spaces
Date: Mon, 28 Oct 2024 19:13:25 +0200 [thread overview]
Message-ID: <86frog6thm.fsf@gnu.org> (raw)
In-Reply-To: <87wmhs19rh.fsf@gmail.com> (message from Visuwesh on Mon, 28 Oct 2024 21:48:26 +0530)
> From: Visuwesh <visuweshm@gmail.com>
> Cc: luangruo@yahoo.com, 73752@debbugs.gnu.org, xuan@xlk.me
> Date: Mon, 28 Oct 2024 21:48:26 +0530
>
> > You need to catch this situation in some reproducible recipe. Because
> > up front I don't understand how is this possible: we cache each
> > composition with its font object, which includes the font size (and
> > also slant, weight, etc.), so a different variant of the same font
> > ought to match only cache entries that use the exact same font. Or
> > maybe I don't understand well enough what
> > composition_gstring_put_cache does to compute the hash of a
> > glyph-string header (which is the hash key for a composition)?
>
> Is this hash dependent on the font driver?
No. Only the font used for the composed characters is recorded, not
the font backend which opened it. But fonts are managed by the font
backend, so maybe there's some leakage by that way.
> Also, do we clear the composition cache when all the GUI frames of an
> Emacs daemon are deleted?
No, we don't, not directly. But we clear the face cache, and that
removes the data of the fonts referred by the face cache from the
composition cache. So it's quite possible the composition cache is
left empty when all the frames are deleted.
> The misalignment goes away when I close all
> the GUI frames of the daemon, and open a fresh new GUI frame.
Next time this happens, try one of these two:
M-: (clear-face-cache t) RET
M-: (clear-composition-cache) RET
and see if any of them corrects the problematic display.
Btw, how frequently do you use different frames, and how likely are
you to have different definitions for the same faces on different
frames in the same Emacs session at the same time?
> > But how can this happen? Without a reproducible recipe, which can be
> > reproduced without waiting for too long, it is very hard to
> > investigate this.
>
> I have no idea. This is not easy to reproduce and seems to be heavily
> dependent on the configuration. Although I use a Cairo build (with
> Lucid toolkit), the misalignment is not as severe as OP says and it
> takes a lot more time to reproduce as well. I could never come up with
> a reproducer that takes less time.
The only way I see to investigate this is to wait for this to happen,
then attach GDB to Emacs and look at the problematic compositions in
the cache, comparing them to the corresponding compositions in a fresh
Emacs session. I can tell what to look for with GDB, if that helps.
If we see that two compositions that should be identical differ by
their font objects, say, we'd at least have a lead and a starting
point for further debugging.
next prev parent reply other threads:[~2024-10-28 17:13 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-11 16:18 bug#73752: 29.4; Ligatures are randomly rendered with extra spaces xuan
2024-10-12 8:02 ` Eli Zaretskii
2024-10-12 16:09 ` Yixuan Chen
2024-10-27 10:21 ` Eli Zaretskii
2024-10-27 16:19 ` Visuwesh
2024-10-27 17:19 ` Eli Zaretskii
2024-10-27 17:27 ` Eli Zaretskii
2024-10-27 17:39 ` Yixuan Chen
2024-10-27 17:43 ` Eli Zaretskii
2024-10-27 17:46 ` Yixuan Chen
2024-10-27 19:14 ` Eli Zaretskii
2024-10-27 19:36 ` Yixuan Chen
2024-10-27 19:44 ` Eli Zaretskii
2024-10-27 19:47 ` Yixuan Chen
2024-10-27 20:11 ` Eli Zaretskii
2024-10-27 19:41 ` Yixuan Chen
2024-10-27 20:07 ` Eli Zaretskii
2024-10-27 20:32 ` Yixuan Chen
2024-10-28 14:25 ` Eli Zaretskii
2024-10-28 14:44 ` Yixuan Chen
2024-10-28 14:47 ` Yixuan Chen
2024-10-28 15:05 ` Eli Zaretskii
2024-10-28 15:20 ` Yixuan Chen
2024-10-28 17:19 ` Eli Zaretskii
2024-10-28 17:26 ` Eli Zaretskii
2024-10-28 17:28 ` Yixuan Chen
2024-10-28 18:41 ` Eli Zaretskii
2024-10-28 4:26 ` Visuwesh
2024-10-28 14:59 ` Eli Zaretskii
2024-10-28 15:24 ` Yixuan Chen
2024-10-28 16:18 ` Visuwesh
2024-10-28 17:13 ` Eli Zaretskii [this message]
2024-10-29 10:59 ` Visuwesh
2024-10-29 13:04 ` Eli Zaretskii
2024-10-29 13:54 ` Visuwesh
2024-10-29 14:00 ` Visuwesh
2024-10-29 15:38 ` Eli Zaretskii
2024-10-29 16:46 ` Visuwesh
2024-10-29 17:45 ` Eli Zaretskii
2024-10-30 5:43 ` Visuwesh
2024-10-29 16:51 ` Eli Zaretskii
2024-10-27 17:29 ` Yixuan Chen
2024-10-29 23:14 ` Tim Ruffing
2024-10-30 15:12 ` Eli Zaretskii
2024-10-30 15:45 ` Eli Zaretskii
[not found] ` <mvmikt9zkcq.fsf@suse.de>
2024-10-30 15:47 ` Eli Zaretskii
2024-10-30 17:34 ` Tim Ruffing
2024-10-30 17:46 ` Eli Zaretskii
2024-10-30 18:00 ` Tim Ruffing
2024-10-30 18:57 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=86frog6thm.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=73752@debbugs.gnu.org \
--cc=luangruo@yahoo.com \
--cc=visuweshm@gmail.com \
--cc=xuan@xlk.me \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).