Re: Question about display engine

[Ergus <spacibba@aol.com>]

On Mon, Sep 09, 2019 at 07:00:00PM +0300, Eli Zaretskii wrote:
>> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
>> From: martin rudalics <rudalics@gmx.at>
>> Date: Mon, 9 Sep 2019 09:39:13 +0200
>>
>>  > I fixed that, try now please (it is in savannah already).
>>
>> Thank you.  Works now as expected.
>>
>> I'm still not convinced that it is a good idea to unconditionally run
>> handle_face_prop_general from extend_face_to_end_of_line.  It will
>> penalize processing every line shown in a window even if no attribute
>> processed is affected by a nil :extend attribute.
>
>The penalty is just a call to merge faces and look up the merged face
>in the face cache (which, under most usual circumstances, will always
>find an already realized face in the cache).  If you are worried about
>face merging itself, then don't be: we do this in redisplay all the
>time when displaying buffers, except in the most boring cases (like
>buffer of all-ASCII text in Fundamental mode).
>
>And the alternative is IMO worse: it will require tracking all the
>face changes and deciding upon each change whether it does or doesn't
>affect the line extension.

Hi Eli:

About this; I agree that the penalty should be negligible at the end
compared to other things that happens on re-display. But after working
on that parts I recognize that the actual algorithm for merge are
extremely complicated and some parts are redundant. All the code is full
of conditions and branch divergences and the design of faces
infrastructure could be more efficient.

Code that is used very often like "PRODUCE_GLYPHS" checks 3 if conditions
every time (we should unify at least the if/else to bypass directly to
the pointer, asserting that it is always initialized in terminal or gui).

face_at_buffer_position and merge_face_ref are actually full of nested
and nested conditional calls and even (direct and indirect) recursive
calls. Some functions that could call merge_named_face I think they call
merge_face_ref instead (with the extra checks and divergences). While
other "low level" calls at the end also call merge_face_ref (probably
for safety) ex get_lface_attributes, merge_face_vectors and so on.

I understand that all this is probably negligible... but all that
inhibits many optimizations very important these days like code
inlining, branch prediction and vectorization. But also a big part of
the code is needed just because the divergence between the tui and the
gui code... if we unify the interfaces; then an important part of the
code will be simplified and reduced and easier to maintain and modify.