From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Kevin Yu" Newsgroups: gmane.emacs.devel Subject: Re: Analysis of redisplay performance on Windows Date: Mon, 28 Jul 2008 10:11:09 +0800 Message-ID: <42b562540807271911u36b016f2ke0990a455c2b521@mail.gmail.com> References: <87od4kuis1.fsf@stupidchicken.com> <488C45FF.2040509@gnu.org> <87tzebnizu.fsf@stupidchicken.com> <488CE8F6.5080001@gnu.org> <87iqurhupv.fsf@stupidchicken.com> <488CEE6B.6020600@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_22182_21790919.1217211069525" X-Trace: ger.gmane.org 1217211093 24413 80.91.229.12 (28 Jul 2008 02:11:33 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 28 Jul 2008 02:11:33 +0000 (UTC) Cc: Chong Yidong , emacs-devel@gnu.org To: "Jason Rumney" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jul 28 04:12:22 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1KNIDc-0001G3-9S for ged-emacs-devel@m.gmane.org; Mon, 28 Jul 2008 04:12:12 +0200 Original-Received: from localhost ([127.0.0.1]:59424 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KNICi-0006WI-5P for ged-emacs-devel@m.gmane.org; Sun, 27 Jul 2008 22:11:16 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KNICf-0006WD-9c for emacs-devel@gnu.org; Sun, 27 Jul 2008 22:11:13 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KNICe-0006Vz-Np for emacs-devel@gnu.org; Sun, 27 Jul 2008 22:11:12 -0400 Original-Received: from [199.232.76.173] (port=57535 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KNICe-0006Vo-LJ for emacs-devel@gnu.org; Sun, 27 Jul 2008 22:11:12 -0400 Original-Received: from ti-out-0910.google.com ([209.85.142.184]:62236) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KNICd-0000Ta-Uj for emacs-devel@gnu.org; Sun, 27 Jul 2008 22:11:12 -0400 Original-Received: by ti-out-0910.google.com with SMTP id u5so1912744tia.10 for ; Sun, 27 Jul 2008 19:11:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=5sAlJp4HxO3LcmUco4t2bkF1xwof+ELO2gUQ3XPqduo=; b=FkgtqPyKovzDkiaBj1AEOa5OUtFdjKXmV03xo1arDw4SIlohmjkzkWW8iWr9nENJ9s xMWrhJiRGvehdZ1Pot21wiZWE98q22CAhihBn8Ny4oCyxTCmcNC+rt9D72NDvA7y9vn3 pJamUkc/URxvvjKb50h1e+7bc+ta1d/rlsck4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=iA8IXNhe4hkXf24vfIxvDObI/3bT5yky+S0qrGylhppFFjSBDreHawKLSIBDqGGXlL dO9g7eaESqOfbVU0Jq51/j+lAsQ40B+S2fQM0ofgyqrC7ClpOkmYyGlH07lOQ/D/2QXt zNEeiy7tyV24Cb/B6qwMrQV0ZyLq4eywk5rJQ= Original-Received: by 10.110.84.2 with SMTP id h2mr5146694tib.7.1217211069534; Sun, 27 Jul 2008 19:11:09 -0700 (PDT) Original-Received: by 10.110.28.7 with HTTP; Sun, 27 Jul 2008 19:11:09 -0700 (PDT) In-Reply-To: <488CEE6B.6020600@gnu.org> X-detected-kernel: by monty-python.gnu.org: Linux 2.6 (newer, 2) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:101612 Archived-At: ------=_Part_22182_21790919.1217211069525 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, On Mon, Jul 28, 2008 at 5:53 AM, Jason Rumney wrote: > Chong Yidong wrote: > > Jason Rumney 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. ------=_Part_22182_21790919.1217211069525 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
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.

------=_Part_22182_21790919.1217211069525--