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: Unfreezing the display during auto-repeated scrolling. Date: Sun, 26 Oct 2014 22:15:30 +0000 Message-ID: <20141026221530.GF4397@acm.acm> References: <87y4s9rgi9.fsf@fencepost.gnu.org> <83zjcpa11g.fsf@gnu.org> <20141021171403.GB3035@acm.acm> <83oat59ucc.fsf@gnu.org> <20141021183807.GD3035@acm.acm> <20141026124333.GA4397@acm.acm> <83h9yq4w5g.fsf@gnu.org> <20141026200313.GE4397@acm.acm> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1414361809 29674 80.91.229.3 (26 Oct 2014 22:16:49 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 26 Oct 2014 22:16:49 +0000 (UTC) Cc: Eli Zaretskii , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Oct 26 23:16:40 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 1XiW76-0006xY-5w for ged-emacs-devel@m.gmane.org; Sun, 26 Oct 2014 23:16:40 +0100 Original-Received: from localhost ([::1]:58515 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XiW75-0002rJ-L9 for ged-emacs-devel@m.gmane.org; Sun, 26 Oct 2014 18:16:39 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34710) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XiW6l-0002qN-Kn for emacs-devel@gnu.org; Sun, 26 Oct 2014 18:16:27 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XiW6e-00012X-4J for emacs-devel@gnu.org; Sun, 26 Oct 2014 18:16:19 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:16354 helo=mail.muc.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XiW6d-00012N-RP for emacs-devel@gnu.org; Sun, 26 Oct 2014 18:16:12 -0400 Original-Received: (qmail 64190 invoked by uid 3782); 26 Oct 2014 22:16:10 -0000 Original-Received: from acm.muc.de (pD951867E.dip0.t-ipconnect.de [217.81.134.126]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 26 Oct 2014 23:16:09 +0100 Original-Received: (qmail 12209 invoked by uid 1000); 26 Oct 2014 22:15:30 -0000 Content-Disposition: inline In-Reply-To: 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:175877 Archived-At: Hello, Stefan. On Sun, Oct 26, 2014 at 04:42:38PM -0400, Stefan Monnier wrote: > I'm not sure exactly what to think here. > I think it is very desirable to try and come up with ways to speed up > redisplay in cases such as auto-repeated scrolling. > It seems that Alan's patch has a fairly small impact on the C code (in > terms of its structure, not necessarily in terms of the end result), > which is good. > But even better would be something that has no impact at all on the > C code. Of course, I'm biased: I hacked my own defer-lock.el before > Simon Marshall published his. > So, I'd be in favor of trying to solve this at the Elisp level, ... I don't think this is possible. At least some minimal, finicky changes will be needed where xdisp.c calls fontification functions. (See below). > ... i.e. inside jit-lock. I think the result might even be better than > Alan's patch because it should let Emacs keep up with scrolling much > more easily (tho displaying un-font-locked content while scrolling). The problem is, _every_ scroll operation into unfontified territory is calling Fvertical_motion (or worse in the GUI case). Fvertical_motion calls start_display calls init_iterator calls reseat calls handle_stop calls handle_fontified_prop. At this stage, _nothing_ can stop handle_fontified_prop running fontification-functions causing the fontification of >= jit-lock-chunk-size (500) bytes. Well, my patch stopped this, but nothing else currently in the system can. 500+ bytes is about a fifth of the 2500 bytes which fit on my 65 line screen, so fontifying them is going to take ~.017s (see other email threads for details of these measurements). My auto-repeat repeat rate is every 0.024s, leaving 0.007s for other processing if Emacs is going to keep up. It can't; 0.007s isn't enough. The above fontification is happening on _every_ scroll operation, even though the fontified text is never going to appear on the screen. The sole purpose of this fontification is to work out how big (in pixels) characters are. And this is in the tty case. The display code has been optimised for variable sized characters, and all possibilities of optimising for the very common case of uniform sized characters has been thrown out the window. My patch was a way for a user, in effect, to tell Emacs that his characters are all the same size. Something's got to give. Maybe Eli's suggestion of rewriting scroll-up and scroll-down from scratch in Elisp could work, but if I'm not mistaken, there's no infrastructural support for window lines, etc., which doesn't involve fontification. This would have to be written. If movement on a window absolutely requires fontified characters, then some means will need to be found for the display code to tell jit-lock HOW MUCH needs fontifying, and for that amount to be much less than 500 bytes in the non-display case. > What I suggest is to refine jit-lock-defer such that jit-lock is > deferred if there's input pending. > I understand there's an underlying problem here, which is that "input > pending" is something that's not tested reliably. Maybe we will need to > try and fix this as well. As already pointed out, even one jit-lock-chunk-size fontification per 0.024s in C Mode is going to overfill the event queue, and that's with nothing actually being drawn on the screen. One might hold that it is unreasonable to expect Emacs to keep up with 42 PageDown's per second with a 65 line window on a mere 2.6 Ghz processor. I disagree. One might argue that CC Mode fontification should be speeded up. Yes, it should, but it's not ever going to be speeded up by an order of magnitude. Even in Emacs Lisp Mode, fontifying and displaying a 65 line screen averages out at 0.018s, compared with a 0.024s repeat rate. There's simply no spare processing capacity for frivolous jit-lock-chunk-size'd fontifications. Something's got to give. > Stefan -- Alan Mackenzie (Nuremberg, Germany).