From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: Aborting display. Is this possible? Date: Tue, 21 Oct 2014 10:58:25 +0000 Message-ID: <20141021105825.GA3035@acm.acm> References: <20141019141712.GB3197@acm.acm> <83lhoccdv7.fsf@gnu.org> <20141019154255.GC3197@acm.acm> <83egu4c4om.fsf@gnu.org> <20141020110949.GA2947@acm.acm> <8338aidbcq.fsf@gnu.org> <20141020185757.GD2947@acm.acm> <83lhoabl2x.fsf@gnu.org> <20141020210819.GE2947@acm.acm> <87y4s9rgi9.fsf@fencepost.gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1413889180 29487 80.91.229.3 (21 Oct 2014 10:59:40 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 21 Oct 2014 10:59:40 +0000 (UTC) Cc: emacs-devel@gnu.org To: David Kastrup Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Oct 21 12:59:33 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XgXA0-0004Os-FE for ged-emacs-devel@m.gmane.org; Tue, 21 Oct 2014 12:59:28 +0200 Original-Received: from localhost ([::1]:49498 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XgX9z-0008Cr-P6 for ged-emacs-devel@m.gmane.org; Tue, 21 Oct 2014 06:59:27 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52741) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XgX9r-0008Cj-Cd for emacs-devel@gnu.org; Tue, 21 Oct 2014 06:59:25 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XgX9g-0000cf-Rk for emacs-devel@gnu.org; Tue, 21 Oct 2014 06:59:19 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:50329 helo=mail.muc.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XgX9g-0000c5-IL for emacs-devel@gnu.org; Tue, 21 Oct 2014 06:59:08 -0400 Original-Received: (qmail 82161 invoked by uid 3782); 21 Oct 2014 10:59:06 -0000 Original-Received: from acm.muc.de (pD9519421.dip0.t-ipconnect.de [217.81.148.33]) by colin.muc.de (tmda-ofmipd) with ESMTP; Tue, 21 Oct 2014 12:59:05 +0200 Original-Received: (qmail 3639 invoked by uid 1000); 21 Oct 2014 10:58:25 -0000 Content-Disposition: inline In-Reply-To: <87y4s9rgi9.fsf@fencepost.gnu.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-detected-operating-system: by eggs.gnu.org: FreeBSD 8.x X-Received-From: 193.149.48.1 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:175631 Archived-At: Hello, David. On Tue, Oct 21, 2014 at 10:09:18AM +0200, David Kastrup wrote: > Alan Mackenzie writes: > > I'd posit that the absolute correctness isn't all that important after an > > auto-repeating PageDown. > That would mean that if you lean on PageDown, something catches your eye > while leafing through, you stop and press PageUp a few times in order to > locate it, it won't reappear where it caught your eye. Yes, possibly. That's if the "default" face used to calculate positions and occupancy is grossly bigger or smaller than the typical face. But since you've stopped very soon after seeing FOO, the discrepancy typically shouldn't be too large. The other answer is that since in this sort of scrolling only a small proportion of screens actually get displayed (see below), the user will soon stop expecting to be able to eyeball a passing function declaration. At any rate, that situation would be an improvement on the current arrangement, where leaning on PageDown (with font-lock enabled) leads to a frozen screen, which stays frozen long after the key is released. Should the region of the buffer already be fontified (or font-locking disabled), the proposed new behaviour would be the same as the current. I've done some more measurements on my system: Autorepeat: delay between 1st event and 2nd event: 0.168s. delay between subsequent consecutive events: 0.024s. Scrolling operation on non-fontified 65 line window with xdisp.c: mean time: 0.106s standard deviation: 0.046s Scrolling operation on already fontified 65 line window with xdisp.c: mean time: 0.011s standard deviation: 0.0023s By subtracting the above two, the mean time to fontify a screen is 0.095s, to display a fontified screen is 0.011s. Assume that the time to calculate a scrolled position, without fontification, is less than 0.011s. Assume 0.010s. So, by my new scheme, a typical timeline would be: 0.0s Arrival of PageDown event Event queue is empty, so start of fontification of screen 2. 0.095s Fontification done; start of display. 0.106s Display complete. Queue is empty. 0.192s Arrival of PageDown event Event queue is empty, so start of fontification of screen 3. 0.216s Arrival of PageDown event Queued (1) 0.240s Arrival of PageDown event Queued (2) 0.264s Arrival of PageDown event Queued (3) 0.287s Fontification done; start of display 0.288s Arrival of PageDown event Queued (4) 0.298s Display of screen 3 complete. Start scroll command. Queue is non-empty (3), so start calculating new position for screen 4 without fontification. 0.312s Arrival of PageDown event Queued (4) 0.318s Finished calculation of screen 4's position. Start scroll command. Queue is 3; start calculating new screen 5 position without fontification. 0.328s Finished calculation for scree 5. Queue is 2. Start calc for screen 6. 0.336s Arrival of PageDown event Queued (3) 0.338s Finished calc for screen 6. Queue is 2. Start calc for screen 7. 0.348s Finished calc for screen 7. Queue is 1. Start calc for screen 8. 0.358s Finished calc for screen 8. Queue is empty. Start fontification for screen 9. 0.360s Arrival of PageDown event Queued (1) 0.384s Arrival of PageDown event Queued (2) 0.408s Arrival of PageDown event Queued (3) 0.432s Arrival of PageDown event Queued (4) 0.453s Fontification of screen 9 done. Start displaying it. 0.456s Arrival of PageDown event Queued (5) 0.464s Display of screen 9 complete. Start scroll command. Queue is 4, start calculating position for screen 10. 0.475s Finished calc for screen 10. Queue is 3. Start calc for screen 11. 0.480s Arrival of PageDown event Queued (4) 0.486s Finished calc for screen 11. Queue is 3. Start calc for screen 12. 0.497s Finished calc for screen 12. Queue is 2. Start calc for screen 13. 0.504s Arrival of PageDown event Queued (3) 0.508s Finished calc for screen 13. Queue is 2. Start calc for screen 14. 0.519s Finished calc for screen 14. Queue is 1. Start calc for screen 15. 0.528s Arrival of PageDown event Queued (2) 0.530s Finished calc for screen 15. Queue is 1. Start calc for screen 16. 0.541s Finished calc for screen 16. Queue is empty. Start fontification for screen 17. ... 0.636s Finished fontifying of screen 17. Start displaying it. ... 0.647s Display of screen 17 complete. ------------------------------------------------------------------------ So it would appear in a worst case scenario (xdisp.c in a 65 line window), about 5 screens per second would be displayed, approximately every 8 screens. > -- David Kastrup -- Alan Mackenzie (Nuremberg, Germany).