Re: Pixel-based display functions

[Eli Zaretskii]

> From: Lars Ingebrigtsen <address@hidden>
> Cc: address@hidden, address@hidden, address@hidden
> Date: Sat, 07 Feb 2015 22:59:52 +1100
> 
> Eli Zaretskii <address@hidden> writes:
> 
> > A few preliminary questions about this:
> >
> >  . Is it good enough to handle only a single physical line, starting
> >    from a given POSITION argument and ending at the first newline that
> >    follows POSITION?  (Handling of additional lines will then have to
> >    be done in Lisp.)
> 
> If this can be done as fast as collecting the line data in C, that would
> be fine.

What do you mean by "collecting the line data"?

>          But I would assume that there's quite a lot set-up overhead
> before getting started.  For instance, calling `window-text-pixel-size'
> ten times over separate lines instead of once on a region is way slower.
> 
> But if there's no setup overhead, then doing it per line basis would be
> fine. 

There's always setup overhead when using the display engine
subroutines.  Whether it's significant in this case, remains to be
seen.

Since handling more than one line needs the one-line case as its
workhorse anyway, I think I will go with that first, and then extend
it if it's not fast enough for many lines.

> >  . What to assume/do with the various display features, like overlay
> >    and display strings, images, align-to space specs, line-prefix,
> >    etc., that can be pertinent to the portion of text being processed?
> >    The easiest alternative is to handle them "as usual" in redisplay,
> >    i.e. the corresponding glyphs will be produced and included in the
> >    return value.  Is that OK?
> 
> Yes, including all that stuff is necessary to do the line filling.

Do you need to know the "type" of each glyph as well, or are
dimensions enough?

> >    If not, what else is needed for these
> >    use cases?  (Note that if a display or overlay string includes
> >    newlines, this means the result could span multiple screen lines --
> >    will that be a problem?.)
> 
> Hm...  I hadn't though of that.  Well, in the shr case, there are no
> overlays at all, and the only display strings are `align-to' one, I
> think...

Well, align-to will produce a stretch glyph that has no underlying
character -- do you care about that?

And then what about images?