On Mon, Jul 28, 2008 at 5:53 AM, Jason Rumney
<jasonr@gnu.org> wrote:
> 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.