unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Kirill Ignatiev <kirill.ignatiev@gmail.com>
Cc: swiesner@lunaryorn.com, 19266@debbugs.gnu.org
Subject: bug#19266: 24.4; Font-related window redrawing delays on OS X
Date: Sun, 07 Dec 2014 18:09:05 +0200	[thread overview]
Message-ID: <83fvcrzbku.fsf@gnu.org> (raw)
In-Reply-To: <CACe-pWz-NRXCwh9sdogF6CPRbp_xeHNtP=KBUJgM7ywuWVE2NQ@mail.gmail.com>

> Date: Sun, 7 Dec 2014 00:50:01 -0500
> From: Kirill Ignatiev <kirill.ignatiev@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>, 19266@debbugs.gnu.org
> 
> I find that many faces that were previously used get garbage collected
> (I see macfont_close being called from cleanup_vector), but I don't
> know how faces are stored, nor do I understand why they are no longer
> referenced (common sense suggests that they should remain in memory as
> long as the buffer that used them is still there).

Face realizations are not specific to buffers, they are specific to
frames.  So the same face can be realized differently on each frame,
and the same buffer displayed on 2 different frames might look
differently.

OTOH, a given face can be used by many buffers on a frame.

So we cannot easily make a simple one-to-one connection between
buffers and faces they use.

> It seems that the faces are not actively used for displaying the
> buffer, but can be expected to be reused in a short time (e.g.,
> region face or comment face).

You forgot the 'default' face, by far the most reused face.

Also, Emacs consults the face every time it needs to display a
character which uses that face.  So caching is really a necessity.

> Can someone explain where faces are stored and why they are no longer
> referenced, even though the buffer that used them is still active?

Realized faces are stored in the frame's face_cache.  As for the
second part of your question, I hope I clarified the issue at least to
some extent.

> I am not sure if this is related to this bug, but there is a constant
> CLEAR_FACE_CACHE_COUNT (=500) that causes face cache to be cleared
> every 500 redisplays. Does anyone understand why this is really
> necessary?

Because we don't really know when a face is no longer needed.
Tracking that could be more hassle than throwing the cache away from
time to time.

Anyway, if you enlarge that number 100-fold, does the problem go away?
If not, then this is not the cause of your problem.

Also, font objects are stored and maintained differently than faces.
So I'm not sure you are on the right track looking into faces.

Thanks.





  reply	other threads:[~2014-12-07 16:09 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-04  7:13 bug#19266: 24.4; Font-related window redrawing delays on OS X Kirill Ignatiev
2014-12-04  7:30 ` Eli Zaretskii
2014-12-04  7:41   ` Kirill Ignatiev
2014-12-04  8:03     ` Eli Zaretskii
2014-12-04  8:20       ` Kirill Ignatiev
2014-12-04  9:55   ` Sebastian Wiesner
2014-12-04 10:17     ` Eli Zaretskii
2014-12-04 10:19       ` Sebastian Wiesner
2014-12-07  5:50         ` Kirill Ignatiev
2014-12-07 16:09           ` Eli Zaretskii [this message]
2014-12-10 23:50             ` Kirill Ignatiev
2014-12-11 17:45               ` Eli Zaretskii
2014-12-12  2:10                 ` Kirill Ignatiev
2014-12-12  8:06                   ` Eli Zaretskii
2014-12-17  1:35                     ` Kirill Ignatiev
2014-12-17  2:13                       ` Kirill Ignatiev
2014-12-12  8:29                   ` Sebastian Wiesner
2014-12-12  9:33                     ` Kirill Ignatiev
2014-12-12 10:56                       ` Eli Zaretskii
2022-04-30 15:44 ` Lars Ingebrigtsen
2022-05-02 16:22   ` Kirill Ignatiev
2022-05-03  9:05     ` Lars Ingebrigtsen

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=83fvcrzbku.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=19266@debbugs.gnu.org \
    --cc=kirill.ignatiev@gmail.com \
    --cc=swiesner@lunaryorn.com \
    /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).