bug#12463: 24.2; pos-visible-in-window-p gets slower over time

[Matt Lundin]

Jörg Walter <jwalt@garni.ch> writes:

> I've done some additional tests: It does *not* happen with Ubuntu's
> emacs23 (23.3.1). Just for cross-checking, I ran Win32 emacs 24.2 once
> via wine and once in VirtualBox+WinXP, in both cases no bug.
>
> It *does* happen with Ubuntu's emacs24 (24.1.1), which is where I
> first noticed the problem. It also happens on all X toolkits (gtk,
> gtk3, athena, lucid).

Does it happen when using x instead of xft as the font backend? I have
found that xft rendering is sluggish in emacs 24 (on Arch Linux, in my
case). A single call to pos-visible-in-window-p can take as much as 0.3
secs according to ELP (e.g., when opening an outline heading, especially
if it contains multi-byte encodings). This slowdown does not occur when
xft is turned off (i.e, by placing "Emacs.FontBackend: x" in
.Xresources).

AFAICT, the bottleneck seems to be in the emacs xft rendering. I tested
this by opening two frames showing the same outline buffer. One of the
frames was a X frame using xft fonts; another frame was running in a
console (urxvt, which also uses xft rendering but shows no similar
slowdown). When opening an outline entry containing multibyte
characters, it appeared instantly in the console frame but only after a
substantial lag on the X frame.

In other words, the culprit may be something other than
pos-visible-in-window-p. For instance, when running emacs on x with xft
enabled, I find it can take as much as 3-4 seconds (according to elp) to
create a new frame with C-x 5 2. When running emacs on x with xft
disabled, new frames are created immediately.

Best,
Matt