Re: Analysis of redisplay performance on Windows

["Kevin Yu" <yujie052@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2333 bytes --]

Hi,

On Mon, Jul 28, 2008 at 5:53 AM, Jason Rumney <jasonr@gnu.org> wrote:

> Chong Yidong wrote:
> > Jason Rumney <jasonr@gnu.org> writes:
>
> > What you wrote seems to imply that left_overwritten and
> > right_overwritten aren't really the problem; they have a performance
> > impact simply because they cause more glyphs to be drawn (i.e., for
> > redrawing overwritten glyphs).  But the ultimate problem is that drawing
> > glyphs is a much slower operation, compared to GNU/Linux.  The question
> > is, what's the reason for this slowness, and can we fix it?
>
> One difference between Emacs 22 and 23 is that we compute glyph indexes
> properly in Emacs 23, while on 22 we use unicode code points. Since we
> call font->encode_char once per character rather than for a whole run,
> the overhead of selecting fonts into the GC is multiplied. As I
> suggested in my earlier email, new functions in the font backend
> interface to select a font for working with and releasing it when done,
> would help, as we could then skip doing this in functions like
> encode_char and text_extents.


I have tried to comment out the font selecting and restoring code in
w32font_encode_char(so using the default font), but the issue still exists.

Here's my analysis, anyway it may be wrong.

When you hold down "C-n" at the bottom line of window you will notice that
half of the screen is updated and half of it left blank. The rest will be
updated when you release the key. It seems like at that time emacs is busy
with handling user input other than redisplay after scrolling. In other
words Emacs hangs the redisplay routine between scrolling and updating other
parts. It's unacceptable. I have trace the code and find that
scrolling_window in the function update_window almost never returns 1, so
emacs have the chance to process user input when redisplay.

But the scrolling job is done by scrolling_window when it returns 1. It
confuses me a lot. At last I found that the x_scroll_run function is also
called by some subroutine of function internal_condition_case_1 in file
xdisp.c line 11895. This function scrolls part of the window back, and then
emacs get the chance to handle user input in update_window? Is that true?

Anyway, all the above should be the same on all platform why it lags on
windows? I haven't traced it on Linux.

[-- Attachment #2: Type: text/html, Size: 2842 bytes --]