[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: |
Sat, 31 Aug 2019 10:57:40 +0300 |
> Cc: address@hidden, address@hidden
> From: martin rudalics <address@hidden>
> Date: Sat, 31 Aug 2019 09:29:13 +0200
>
> > I thought we already agreed that there's no other way of having this
> > feature than to realize a face at each EOL.
>
> Then that's where we have been miscommunicating. The whole idea
> behind the extend_background, extend_underline, ... bits was to avoid
> the full handle_stop rigmarole at EOL, like finding the overlays and
> text properties and processing them in the right order.
We don't need everything from handle_stop, we only need the parts that
affect the face.
> The only missing step is to process the :extend attribute of any face
> merged. For the normal background, this is the value of the
> :background attribute of the last face that specified that attribute
> and was merged in. For the extended background this is the value of
> the :background attribute of the last face that specified that
> attribute, had the :extend attribute set and was merged in.
>
> To put this into praxis, the face merger would maintain a shadow copy
> of the background value. That shadow value would not get overwritten
> when merging in the :background attribute of a face that does not have
> the :extend attribute set. Eventually, we would wind up with two,
> possibly distinct values of the background to realize - one for the
> normal and the shadow value for the extended background.
The face merger doesn't maintain any state, so I don't think this is
easily done.
> If we wanted to realize both faces - the one to use for the current
> face and the one to use for extension - immediately (eagerly as I
> coined it earlier), we could do that right after merging terminates.
> We probably would set up a pointer to the realized face to use for
> extension, so the iterator, when arriving at EOL, would find it right
> away and make it current. That's all.
>
> But we probably don't want to realize the face to use for extension
> immediately and do it - as we agreed earlier - lazily when the
> iterator arrives at EOL.
If lazy realization is hard to implement, there's nothing wrong with
realizing both faces immediately, at each stop position.
> Note: We could also try to find out whether there _is_ another stop
> position before the next EOL after merging faces and, if there's none,
> realize the extended face eagerly, but I'm not sure whether this idea
> can be incorporated easily.
Right.
> > I don't see how this will help anything. To remind you: the display
> > engine manipulates face IDs, it doesn't know anything about the faces
> > themselves, and in particular cannot magically exchange a face's
> > background color for some other color.
>
> But it knows where the background of a realized face is stored and
> could easily realize a new face which is the same but for a different
> background swapped in. Hardly rocket science for the display engine.
If we extend faces to keep the information about how to do that, then
yes, this can be done.
> So what we could do is to simply maintain a vector of the values for
> background, underline, etc. calculated at the last real stop position
> and whenever the display engine encounters a newline, realize a face
> with the values of that vector replacing the current values, use that
> face for the spaces at the rest of the line, and restore the old face
> for the normal text on the next line (unless we have several newlines
> in a row and similar optimizations).
That's possible, assuming faces are extended as mentioned above. But
I'm not sure realizing both faces immediately ("eagerly") will not be
an easier solution.
> BTW: One problem with Ergus' proposal is that hacks like the one
> proposed for Bug#15934 won't work any more. For that bug, we could
> obviously set the :extend attribute of the respective highlight line
> face but all instances in the wild using the same hack already would
> be affected by our change.
Yes, of course.
- Re: Question about display engine, (continued)
- Re: Question about display engine, Ergus, 2019/08/30
- Re: Question about display engine, martin rudalics, 2019/08/29
- Re: Question about display engine, Eli Zaretskii, 2019/08/28
- Re: Question about display engine, martin rudalics, 2019/08/29
- Re: Question about display engine, Eli Zaretskii, 2019/08/29
- Re: Question about display engine, martin rudalics, 2019/08/30
- Re: Question about display engine, Eli Zaretskii, 2019/08/30
- Re: Question about display engine, martin rudalics, 2019/08/31
- Re: Question about display engine,
Eli Zaretskii <=
- Re: Question about display engine, martin rudalics, 2019/08/21
- Re: Question about display engine, Eli Zaretskii, 2019/08/08
- Re: Question about display engine, martin rudalics, 2019/08/09
- Re: Question about display engine, Eli Zaretskii, 2019/08/10
- Re: Question about display engine, Stefan Monnier, 2019/08/10
- Re: Question about display engine, Eli Zaretskii, 2019/08/10
- Re: Question about display engine, martin rudalics, 2019/08/11
- Re: Question about display engine, martin rudalics, 2019/08/11
- Re: Question about display engine, Eli Zaretskii, 2019/08/08
- Re: Question about display engine, Ergus, 2019/08/08