Re: Pixel-based display functions

[Eli Zaretskii <eliz@gnu.org>]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: rudalics@gmx.at, monnier@IRO.UMontreal.CA, emacs-devel@gnu.org
> Date: Fri, 06 Feb 2015 20:47:40 +1100
> 
> shr inserts text as long lines into the buffer, and I then use
> `vertical-motion' to go to the desired width, and then backtracking
> finding a fill point using the kinsuko algorithm.  Then a newline is
> inserted, and we repeat until the line is completely filled.

When you "repeat", do you start from the part of the line that's left,
without the part that is before the just-inserted newline, or from the
original long one?  The time it takes vertical-motion to do its job
will be smaller if the line is shorter.

Also, try invoking vertical-motion from a position that is not
immediately after a newline, I think this might speed it up a little
more.

> >> But it's all kinda moot since `window-text-pixel-size' doesn't work on
> >> non-displayed buffers (yet).
> >
> > window-text-pixel-size is equivalent to vertical-motion, so I don't
> > understand why you need both.  Can you explain?
> 
> `window-text-pixel-size' tells me what width I ended up with, while
> `vertical-motion' goes to an approximate fill point.  

Why do you need to know what width you ended up with?  Or maybe I
don't understand "ended up with" when -- before or after
vertical-motion did its job?  IOW, do you need window-text-pixel-size
for measuring the long unfilled line, or the lines after filling?

> >> I wonder whether a faster interface would be to have a version of
> >> `window-text-pixel-size' that returns a vector of glyph sizes.
> >
> > ??? Isn't that font-get-glyphs that you already tried?  If not, why
> > not?  What API would you like to have for that hypothetical function?
> 
> I though we established pretty thoroughly that for `font-get-glyphs' to
> be a solution, we'd have to reimplement too much of the redisplay
> algorithm in Emacs Lisp (what with segmenting on scripts and faces, and
> then having to see whether a script uses multiple fonts, etc).  And it
> was too slow during my testing.

So what kind of API would you like to have?

> >> Of course, computing the vector may be unreasonably slow.
> >
> > It is again equivalent to vertical-motion and font-get-glyphs, so it's
> > not slow.  But I don't yet see the issue clearly enough to tell what
> > could be done for you, so please post more information about what you
> > are trying to do.
> 
> It would be equivalent to a `window-text-pixel-size' that advances one
> character at a time (since we'd avoid the entire `font-at' problem), and
> returns an vector of pixel points (instead of calling move_it_to just
> once).

You are describing an implementation.  Please describe the API and the
contract instead.

Also, as long as you use these functions, there's still a problem with
visual vs logical order that needs to be solved.