Re: Question about display engine

[Eli Zaretskii]

> Date: Tue, 17 Sep 2019 04:17:26 +0200
> From: Ergus <address@hidden>
> Cc: address@hidden, address@hidden
> 
> >>>>The filter now in merge_ref only works when !CONSP(ref_name). As it only
> >>>>bypass the extra parameter to merge_named... it this right in the
> >>>>general case?
> >>
> >>I think we should support all the cases, otherwise the feature will
> >>behave inconsistently, and we will get bug reports.
> >>
> >About this; the problem is that in the general case I'm not sure what's
> >the "right" behavior for the other cases. When !CONSP(ref_name) it means
> >that the parameter is a face_name; but in the other cases it means that
> >we are explicitly specifying the attributes as a cons list or as
> >:atribute value pairs... What's expected to happen in those cases??
> >
> Hi:
> Any Idea about this? Could you suggest what to do when CONSP(ref_name)
> is true?

I will reply to this soon, too swamped now.

> >>>Could you suggest (if any) if there are some conditions we can use to
> >>>avoid the call to handle_face_prop_general in some cases?
> >>
> >>Why, did you see any tangible slow-down of redisplay due to these
> >>changes?
> >
> No actually, but I think that  there should be many cases where we could
> avoid calling the new function. So it is better to put them and avoid
> unneeded calls.
> 
> For example when face_id is the default_face_id maybe?

Yes, for the default face ID it might be a good idea to add some
optimization, as that will be the most frequent case.  But beware of
remapped default face, though.