From owner-ntemacs-users@cs.washington.edu Thu Feb 19 05:56:47 1998 X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] [nil "Thu" "19" "February" "1998" "13:20:54" "GMT" "Andrew Innes" "andrewi@harlequin.co.uk" nil "56" "Re: NTEmacs 20.2 vs NT4 System Tray + running two versions." "^From:" nil nil "2" nil nil nil nil] nil) Received: from joker.cs.washington.edu (joker.cs.washington.edu [128.95.1.42]) by june.cs.washington.edu (8.8.7+CS/7.2ju) with SMTP id FAA12158 for ; Thu, 19 Feb 1998 05:56:47 -0800 Received: from trout.cs.washington.edu (trout.cs.washington.edu [128.95.1.178]) by joker.cs.washington.edu (8.6.12/7.2ws+) with ESMTP id FAA54797 for ; Thu, 19 Feb 1998 05:56:46 -0800 Received: (majordom@localhost) by trout.cs.washington.edu (8.8.5+CS/7.2ws+) id FAA00363 for ntemacs-users-outgoing; Thu, 19 Feb 1998 05:21:48 -0800 (PST) Received: from june.cs.washington.edu (june.cs.washington.edu [128.95.1.4]) by trout.cs.washington.edu (8.8.5+CS/7.2ws+) with ESMTP id FAA00359 for ; Thu, 19 Feb 1998 05:21:44 -0800 (PST) Received: from holly.cam.harlequin.co.uk (holly.cam.harlequin.co.uk [193.128.4.58]) by june.cs.washington.edu (8.8.7+CS/7.2ju) with ESMTP id FAA10950 for ; Thu, 19 Feb 1998 05:21:40 -0800 Received: from shirow.long.harlequin.co.uk (shirow.long.harlequin.co.uk [193.128.93.50]) by holly.cam.harlequin.co.uk (8.8.4/8.8.4) with ESMTP id NAA05834; Thu, 19 Feb 1998 13:21:32 GMT Received: from gridlock.long.harlequin.co.uk (gridlock.long.harlequin.co.uk [193.128.93.234]) by shirow.long.harlequin.co.uk (8.8.4/8.8.4) with SMTP id NAA04905; Thu, 19 Feb 1998 13:20:54 GMT Message-Id: <199802191320.NAA04905@shirow.long.harlequin.co.uk> In-reply-to: <00c601bd3cc9$e6352ea0$f409a8c0@dima> (dyaitskov@insystems.com) Precedence: bulk From: Andrew Innes Sender: owner-ntemacs-users@cs.washington.edu To: dyaitskov@insystems.com CC: ntemacs-users@cs.washington.edu Subject: Re: NTEmacs 20.2 vs NT4 System Tray + running two versions. Date: Thu, 19 Feb 1998 13:20:54 GMT On Wed, 18 Feb 1998 19:04:07 -0500, "Dmitry Yaitskov" said: >>Do both emacsen therefore use the lisp, info and other directories for >>20.2.1? > >No, they seem to be intelligent enough to correctly determine their base dir >(i.e. the one they were started from), so that all other directories are >also correct. runemacs deliberately sets emacs_dir based on its own location - I added that feature for my own convenience, since I have separate test and normal use builds on my machine. >>Haven't really noticed the speed decrease as yet, not enough time to >>spare :-( > >I have ctrl-up mapped to scroll up, and ctrl-down to scroll down. In 19.36, >I had to disable the menubar to get acceptable scroll speed (i.e. enough for >window refresh to keep up with my key repeat rate). In 20.2, even though I >have no menubar, pressing and holding ctrl-up or down results in ugly >refreshes of only about upper 1/3 of the window. The rest is not refreshed, >which makes scrolling practically useless for me. :(( (and btw, disabling >the scrollbar did not have any effect at all). Last autumn, I did some profiling of the redisplay engine to try and identify the major bottlenecks (which isn't terribly relevant any more, as Emacs will soon have a brand new redisplay engine). However, I also compared the performance of 20.2 with 19.34.6, out of curiosity. I found that 20.2 was actually measurably quicker than 19.34.x in some tests, and a bit slower in others. Overall, there wasn't much difference. My primary testing procedure was to time how long it takes to execute (next-line 1) 3000 times (while displaying the etc/NEWS file), calling (sit-for 0) after each move to force a full redisplay. (I noticed a few minor bug fixes in 20.2 that would affect whether certain optimizations are used, which were not being used in 19.34. I suspect that is mainly responsible for any differences I observed. Note that my tests didn't exercise the MULE code, since the NEWS file is in plain ascii.) The main outcome of my testing was actually to determine that calculating the line and column position on the modeline (or just one of them) slows down redisplay significantly - almost 100% for both of them (ie. redisplay time is nearly doubled by enabling line-number-mode and column-number-mode). I also noticed that side-by-side windows showing the same buffer were much slower than one window on top of the other, which was the main problem I hoped to address. Anyway, since a new redisplay engine has already been written, most of this discussion is now moot. The new engine has been designed from scratch to work well on pixel-oriented displays, and should avoid at least some of the inefficiencies of the old engine because of that. It also supports proportionally spaced fonts, and mixing fonts of different heights and widths, so is a major improvement in that regard too. AndrewI