[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Pixel-based display functions

From: Eli Zaretskii
Subject: Re: Pixel-based display functions
Date: Tue, 10 Feb 2015 17:48:45 +0200

> From: Lars Ingebrigtsen <address@hidden>
> Cc: address@hidden, address@hidden
> Date: Tue, 10 Feb 2015 15:48:15 +1100
> > 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).  :-)

Thanks, these speed-ups match my expectations, given the amount of
code I bypass when this new argument is provided.

> 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.

Well, you insert those lines into the buffer yourself, right?  Can you
find the longest line while you are at it, and insert only it?
AFAICS, that's the only way of making window-text-pixel-size do its
job faster: by making the region FROM..TO it needs to traverse

reply via email to

[Prev in Thread] Current Thread [Next in Thread]