From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: MPS: face-cache Date: Sun, 28 Apr 2024 11:13:06 +0300 Message-ID: <86sez5ucq5.fsf@gnu.org> References: <87r0eqaslt.fsf@gmail.com> <87mspeas8s.fsf@gmail.com> <8634r6uer3.fsf@gnu.org> <86wmohudht.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="8152"; mail-complaints-to="usenet@ciao.gmane.io" Cc: eller.helmut@gmail.com, emacs-devel@gnu.org To: Gerd =?utf-8?Q?M=C3=B6llmann?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Apr 28 10:13:46 2024 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1s0zfO-0001xP-CA for ged-emacs-devel@m.gmane-mx.org; Sun, 28 Apr 2024 10:13:46 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1s0zeq-00015P-13; Sun, 28 Apr 2024 04:13:12 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1s0zeo-000157-N8 for emacs-devel@gnu.org; Sun, 28 Apr 2024 04:13:10 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1s0zeo-00026b-D5; Sun, 28 Apr 2024 04:13:10 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=WI5GRGlPtYxMxCqRLCwl1UVHh7ZtTnHPxNdk4+cQ+KY=; b=dxkOQda+K6JUhw+R/gOX zexVkF1LCHT9b+11DGRrP2zzosWK93B1UQ5s5H7aFH7OPTi8QOUw2LAFkRC62oDJjewvAVP663Qw3 89Ubm+vpjyASwvQ5AqZY34daBDko0xRoOol4/NgPsXiG32JyS6YnPoPsGPjos8TY57i1sg17V5ou1 LlXhbS1b+NFjlHYglm1NPssgXVkXItPDh+WBIGzSitGN3moWB8wM8Ln24Bn+gq5AYW7xanGxjAXjw 7LnNyis1cPgPyPo2LM2RJBATLf/GeNo4scYBIaGhcCOu+Vz1CMFyS4XL2I3H3BCcqAGHogWct2b7A joGCVQDh8VACtQ==; In-Reply-To: (message from Gerd =?utf-8?Q?M=C3=B6llmann?= on Sun, 28 Apr 2024 10:05:03 +0200) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:318254 Archived-At: > From: Gerd Möllmann > Cc: eller.helmut@gmail.com, emacs-devel@gnu.org > Date: Sun, 28 Apr 2024 10:05:03 +0200 > > Eli Zaretskii writes: > > > 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; That function calls the 'list' method of each of the registered font drivers to produce fonts that match a given spec: for (; driver_list; driver_list = driver_list->next) if (driver_list->on && (NILP (ftype) || EQ (driver_list->driver->type, ftype))) { Lisp_Object cache = font_get_cache (f, driver_list->driver); ASET (scratch_font_spec, FONT_TYPE_INDEX, driver_list->driver->type); val = assoc_no_quit (scratch_font_spec, XCDR (cache)); if (CONSP (val)) val = XCDR (val); else { Lisp_Object copy; val = (driver_list->driver->list) (f, scratch_font_spec); /* We put zero_vector in the font-cache to indicate that no fonts matching SPEC were found on the system. Failure to have this indication in the font cache can cause severe performance degradation in some rare cases, see bug#21028. */ if (NILP (val)) val = zero_vector; else val = Fvconcat (1, &val); copy = copy_font_spec (scratch_font_spec); ASET (copy, FONT_TYPE_INDEX, driver_list->driver->type); XSETCDR (cache, Fcons (Fcons (copy, val), XCDR (cache))); } Then it filters the fonts according to some criteria. So my reading of this is that the 'list' method can create font entities, but the list of drivers itself is not used for the font object, only the driver's 'type' (as symbol) is inserted into the FONT_TYPE_INDEX slot of the font entities. IOW, the font objects come from calls to font driver methods, not from the list of drivers.