Re: Pixel-based display functions

[Lars Ingebrigtsen <larsi@gnus.org>]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

> IIRC this "standard width of the default font" matches the unit assumed
> by `vertical-motion', so it should indeed work (IOW, vertical-motion
> will do the equivalent of multiplying its arg by (frame-char-width)
> internally to get a pixel size).

Oh, I see.  Thanks.

I've been doing some benchmarking to get a feel for the speed of
`vertical-motion'.  

shr-tag-body                         100         2.2069731249  0.0220697312
shr-fold-lines                       100         1.2538841410  0.0125388414
shr-fold-line                        1500        1.2457802040  0.0008305201
shr-goto-pixel-column                5000        1.1738643779  0.0002347728

`shr-goto-pixel-column' is just a call to `vertical-motion' separated
out to see how much time it takes.

So, basically, folding 1500 lines takes 1.24s, of which 1.17s is spent
in `vertical-motion' (plus function call overhead).  (It's called a lot
of times because the lines are very long and need to be filled more than
once.)

(benchmark-run 5000 (vertical-motion (cons (/ 700 (frame-char-width)) 0)))
=> (0.942894006 2 0.05716983599999992)

But it's all kinda moot since `window-text-pixel-size' doesn't work on
non-displayed buffers (yet).  But if that could be made to work somehow
(Eli seemed to have an idea here?), I wonder whether a faster interface
would be to have a version of `window-text-pixel-size' that returns a
vector of glyph sizes.  Then that vector could be used both for going to
a column (by just adding until we get to the required pixel count) as
well as for computing the displayed width of each line.

And this would be only one call to this new function per each (long)
line instead of repeatedly calling `vertical-motion' after each line
break has been inserted, so it may be faster.

The glyph width vector would also allow caching of the data, which would
speed up multi-column computation, where each text line is usually
folded more than once to reach an optimal layout.

Of course, computing the vector may be unreasonably slow.  Or not.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/