Re: Question about display engine

[Eli Zaretskii <eliz@gnu.org>]

> Date: Mon, 9 Sep 2019 21:29:34 +0200
> From: Ergus <spacibba@aol.com>
> Cc: rudalics@gmx.at, emacs-devel@gnu.org
> 
> >I don't think I agree.  Given the complexity of the face-related
> >functionalities -- face remapping, the need to recompute all the faces
> >when some basic face changes, the various sources of face-related
> >information for each buffer/string position, etc. -- I find the design
> >and implementation of face code quite elegant and easy to understand,
> >maintain and change.
> >
> I am talking about efficiency.

Efficiency is secondary to clean design and correct implementation.

> It is just not standard. If there is no difference why are there
> different methods to select with if/else?

History, I guess.

> To add one field to the faces it required many modifications.

That isn't a problem in my eyes.

> But then why when the GC fails the lagging is so intense? I
> thought that the main part of the display engine related with GC was the
> faces part.

No, faces code cannot GC.  What causes GC is the calls to Lisp, which
is JIT font-lock and other Lisp hooks.

> >Which interfaces would you like to unify?  I don't think I understand.
> >
> Most of the code conditioned with: if (FRAME_WINDOW_P (f)) could be
> simplified. But I understand that this could be a lot of work and I
> don't know enough about this.

This work is being done, and most of it has been done already.  Some
display features are only possible on GUI frames (multiple fonts, for
example), so such conditions are necessary, at least to some extent.