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 17:14:03 +0000 Message-ID: <20141021171403.GB3035@acm.acm> References: <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> <83zjcpa11g.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1413911930 28646 80.91.229.3 (21 Oct 2014 17:18:50 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 21 Oct 2014 17:18:50 +0000 (UTC) Cc: dak@gnu.org, Stefan Monnier , emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Oct 21 19:18:44 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 1Xgd51-0007Gl-Rh for ged-emacs-devel@m.gmane.org; Tue, 21 Oct 2014 19:18:43 +0200 Original-Received: from localhost ([::1]:52618 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xgd51-0000ik-3P for ged-emacs-devel@m.gmane.org; Tue, 21 Oct 2014 13:18:43 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46744) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xgd1M-0003pg-GK for emacs-devel@gnu.org; Tue, 21 Oct 2014 13:15:01 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xgd1C-0006ar-SE for emacs-devel@gnu.org; Tue, 21 Oct 2014 13:14:56 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:21303 helo=mail.muc.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xgd1C-0006a5-HH for emacs-devel@gnu.org; Tue, 21 Oct 2014 13:14:46 -0400 Original-Received: (qmail 86504 invoked by uid 3782); 21 Oct 2014 17:14:45 -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 19:14:43 +0200 Original-Received: (qmail 4758 invoked by uid 1000); 21 Oct 2014 17:14:03 -0000 Content-Disposition: inline In-Reply-To: <83zjcpa11g.fsf@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:175649 Archived-At: Hi, Eli. On Tue, Oct 21, 2014 at 06:35:23PM +0300, Eli Zaretskii wrote: > > From: Stefan Monnier > > Date: Tue, 21 Oct 2014 10:01:43 -0400 > > Cc: emacs-devel@gnu.org [ ... ] > In any case, the way Alan suggests is not TRT, IMNSHO. We shouldn't > be sacrificing display correctness for speed; AFAIR, we never did > anything like that. What we did was find and implement optimizations > that catered to specific use cases that were deemed important enough. > I see no reason to treat this case differently. > Another data point is this: in the recent years, I've dealt with any > number of bug reports that complained about minor inaccuracies in > scrolling, mostly by fractions of line height or even by a couple of > pixels. My interpretation of this is that our users expect accurate > display, and will not easily tolerate sloppiness. This is a red herring, surely? Tiny fractions, visible, of the line height are totally orthogonal to being one or two lines out (which won't even be visible) after a "sloppy" user action. > So I suggest to turn the table and ask: how come fontification of C > sources is so expensive, and how can we make it faster? It has got slower as it has become more accurate. Users have complained about slight inaccuracies in fontification, too. Fast enough would mean speeding it up by a factor of around 5. I don't think this is practicable. A couple of days ago, I even got auto-repeated PageDown to hang in Emacs LIsp mode. I can't reproduce that at the moment, though. But I applied my timing program to cc-engine.el, and its average time to scroll and display a screen was 0.018s compared with an auto-repeat rate of 0.024s. That's not a lot of free play. > If the Lisp implementation cannot be sped up significantly, let's > implement some of the code in C. Or maybe we are should request less > accurate parsing of the source, at least by default -- e.g., perhaps it > is not very important to display variables in a face that is different > from, say, data types? You're suggesting sacrificing fontification accuracy for scrolling accuracy? :-) > IOW, if the measurements show that redisplay takes 10% of the time, > let's not try to optimize those 10%, but instead concentrate on the > 90%. A very common use case for programming languages is when all the font-lock-* faces are mono-spaced of equal size. This might even be the overwhelming majority of use. Yet the scrolling/display code makes no optimisation for this. In this very common case, it is entirely unnecessary to fontify bits of buffer to work out how much text would fit onto the screen we want to scroll over. The whole point of Jit Lock was that we would only need to fontify the bits of the buffer currently being displayed. This was partly so that mode maintainers could be a bit more relaxed about the speed of font-locking. The scenario of auto-repeat on PageDown suggests that the mechanism wasn't fully thought out. I still say an optimisation to the scrolling code, where an option could specify that all faces are of the same size (or should be deemed to be so) is called for here. -- Alan Mackenzie (Nuremberg, Germany).