[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Question about display engine

From: Eli Zaretskii
Subject: Re: Question about display engine
Date: Fri, 06 Sep 2019 11:55:19 +0300

> Date: Thu, 5 Sep 2019 19:26:09 +0000 (UTC)
> From: Ergus <address@hidden>
> Cc: address@hidden, address@hidden
> I attach here a new patch with all the changes I have just made. After fixing 
> the latest Martin's issue there was
> exposed a new issue maybe related with the initialization per line. (picture 
> attached) 

Thanks.  I admit that I'm confused by your patch: I don't understand
your design of calculating and applying the face used for EOL
extension.  E.g., where's the code that merges only the non-extensible
attributes of the face at buffer position and assigns that face ID of
the calculated face to it->extend_face_id?  And why did you copy all
the lines that assign to it->face_id with similar lines that assign
something similar (sometimes identical) to it->extend_face_id?  And
why do you have to save and restore extend_face_id during some
operations, like we do with it->face_id?  Etc. etc.

Can you post a description of the design and the implementation, to
help me find the light here?  In particular, I don't think I
understand the meaning of "the face should be extended after EOL", if
that face is merged with other faces to realize the face to be
actually used in display.  This semantics seems not to be explained
anywhere, so it's hard to judge whether the implementation satisfies
the requirements/expectations.

> The issue is actually related with the fact that extend_face_id is never 
> restarted to face_id when going back
> from an extend to a non_extend face between lines (for example when mark is 
> active and the iterator crosses
> the pointer to outside the selected region like in the  picture). 

I cannot answer this question because my mental model is the opposite:
that the code should temporarily set face_id to be equal to
extend_face_id when producing glyphs beyond EOL, then reset face_id
back to its previous value.  But your code doesn't fit this mental
model of mine, so I'm probably missing something.

> I made all the  updates of the extend_face_id in the same places where 
> face_id was updated (even when
> uneeded for now.)

This is another place for confusion: I don't understand why
extend_face_id should be updated in all those places.  In my metal
model, extend_face_id is independent of many/most of the factors that
cause us update face_id.

> But I don't see any special function that is called before
> display_line.

face_id is initialized in init_iterator, which is always called once
before the first call to display_line.  Thereafter, any subsequent
call to display_line "inherits" the value of face_id left in the
iterator object at the end of the previous call to display_line.

Whether this fits the logic of using extend_face_id, I cannot say yet;
see the above questions that describe my confusion.

Thanks for working on this.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]