Re: Question about display engine

[martin rudalics]

> Exactly.  More accurately, we have 2 problems: (1) how do you know you
> hit the stop point while going back; and (2) where do you go to
> compute the "next" stop point.  You don't want to know the answers...

I'm not sure.  If that algorithm is newline agnostic, it will have to
be changed if an eager (see below) solution is implemented.

>> ... I obviously have to discontinue disagreeing with that conclusion.
>> But wouldn't that significantly increase the size of the face cache?
>
> It will increase the cache, yes. Whether it will be significant is
> another question; I'm not sure.

In the worst case it would double the size of the cache for
implementing the background extension alone.  This looks like a
veritable ordeal to me.  IIUC we do all this to keep the display
optimizations (where we compare the glyph matrices) simple and
efficient.  Or is there an additional twist to it?

One could argue that if, in the current implementation, the display
element stops right before a newline character and that newline is,
presumably, a separate display element, the overhead remains
unchanged.  But AFAICT, font locking does not necessarily pay immense
attention to newlines (Lisp comments and C strings excluded) so at
least for displaying programming languages the overhead increase might
be significant.

>> Since extend_face_to_end_of_line already switches to the default face
>> when no extension of the region is wanted
>
> It does? where?

I thought it did so here

      /* The last row's blank glyphs should get the default face, to
         avoid painting the rest of the window with the region face,
         if the region ends at ZV.  */
      if (it->glyph_row->ends_at_zv_p)
        it->face_id = default_face->id;
      else
        it->face_id = face->id;

but apparently that's only a red herring.

>> it could also switch to the default face when the extend_background
>> bit is false.  Right?
>
> No.  A face is not just its background color, it's quite a few other
> things.  You only want to reset the background color.  For example, if
> the face of the last character used a larger font, you still want the
> extension to use that larger font, e.g. for the fill-column indicator
> character.
>
> So switching to the default face in this case is wrong, we really need
> to make a face exactly like the one we used, but without the attribute
> that should not be extended.

I currently see two ways to accomplish that: Eagerly, during face
merging, we would have to search for and possibly create the extend
face variation whenever the next stop point finding algorithm
encounters a newline character within the object it examines.  This
means that any display element that contains a newline character also
ends before that character and the entire logic of finding display
elements changes.

A lazy variant would have the display engine itself create the extend
face by demand whenever it encounters a newline character within the
current display element.  This would strike me as more elegant but
also means that the display engine has to scan the face cache and
potentially realize a new face here.

The worst aspect of all this is that there is no simpler solution even
if we attempted a different implementation of the extend logic.
Suppose I used just one single, global variable to turn off/on any
face extensions.  For turning it off, I'd still have to, at the end of
every line, assure that a separate realized face does implement the
"off" interpretation while the "on" interpretation is already provided
by the last face on that line.  Right?

martin