Re: Pixel-based display functions

[Lars Ingebrigtsen]

Eli Zaretskii <address@hidden> writes:

> Please try the latest master, where I implemented that.

Great!

> Contrary to what I wrote above, I decided to interpret the additional
> argument in the same units as the COLS element of the cons cell that
> is the first argument.  I think this is better for consistency and
> also more convenient, since both values are in the same units and both
> can be floats, so no accuracy is lost.
>
> I'd be interested to know if this produces a noticeable speed-up.

I did the measurements with this (over a variable-width text buffer):

(benchmark-run 5000 (let ((start (point))) (vertical-motion (cons (/ 500 
(frame-char-width)) 0) nil 0) (goto-char start)))

Without the column parameter, and starting from beginning-of-line, it
takes 1s.  Starting from the first characters, it takes 0.6s.

With the column parameter, and starting from beginning-of-line, it takes
0.2s.  So improvement makes it about 3x faster than the previous
best-case scenario, and 5x faster than the worst-case scenario (in this
simple test).  :-)

The major single component that takes time when figuring out
multi-column layouts now is the calls to

        (save-window-excursion
          (set-window-buffer nil (current-buffer))
          (window-text-pixel-size ...))

If something could be done to make it faster to find out the (maximum)
pixel width of a (possibly undisplayed) buffer, that would be a great
win, I think.

I'll apply the shr branch stuff to the trunk later today and post some
new ELP traces with the new `vertical-motion' speedups.

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