From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Aborting display. Is this possible? Date: Sun, 19 Oct 2014 21:09:13 +0300 Message-ID: <83egu4c4om.fsf@gnu.org> References: <20141019141712.GB3197@acm.acm> <83lhoccdv7.fsf@gnu.org> <20141019154255.GC3197@acm.acm> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1413742199 23165 80.91.229.3 (19 Oct 2014 18:09:59 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 19 Oct 2014 18:09:59 +0000 (UTC) Cc: emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Oct 19 20:09:50 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 1XfuvN-0007vG-8Q for ged-emacs-devel@m.gmane.org; Sun, 19 Oct 2014 20:09:49 +0200 Original-Received: from localhost ([::1]:40816 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XfuvM-0007Du-NQ for ged-emacs-devel@m.gmane.org; Sun, 19 Oct 2014 14:09:48 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50312) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xfuv5-0007Cs-G7 for emacs-devel@gnu.org; Sun, 19 Oct 2014 14:09:36 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xfuv0-0007iv-Ca for emacs-devel@gnu.org; Sun, 19 Oct 2014 14:09:31 -0400 Original-Received: from mtaout21.012.net.il ([80.179.55.169]:47355) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xfuv0-0007ir-3i for emacs-devel@gnu.org; Sun, 19 Oct 2014 14:09:26 -0400 Original-Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0NDP00400EEEQQ00@a-mtaout21.012.net.il> for emacs-devel@gnu.org; Sun, 19 Oct 2014 21:09:24 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NDP004DFEFNOM60@a-mtaout21.012.net.il>; Sun, 19 Oct 2014 21:09:24 +0300 (IDT) In-reply-to: <20141019154255.GC3197@acm.acm> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.169 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:175569 Archived-At: > Date: Sun, 19 Oct 2014 15:42:55 +0000 > Cc: emacs-devel@gnu.org > From: Alan Mackenzie > > > That's not what happens. What does happen is that redisplay _tries_ > > several times to do its job, right after each PageDown keypress, each > > time starting with the value of point it sees, then abandoning that > > attempt because input arrives before it could finish. > > So if 35 PageDowns are received in a second, it starts redisplay after > each and every one. Yes, unless by the time Emacs finishes processing one PageDown key there's another one in the keyboard queue. > How much time does it take before checking for pending input? It checks for it every cycle through the command loop. IOW, "immediately" after the command bound to PageDown finishes, and control is returned to the main loop. > Could my problem be that this time is short enough that that no > intermediate screen has time to display a fragment, but long enough that > there's a significant pause when the user finally takes her finger of > PageDown? It seems like you think Emacs is able to produce only a partial redraw of the screen; if so, you are wrong: Emacs never does that. Redisplay of each window (or maybe even each frame, I don't recall exactly) is an atomic operation: it is either done completely, or not at all. Emacs checks for pending input at strategic places, so that you never see a partially incorrect display. (Of course, when redisplay-dont-pause is non-nil, as it is by default, pending input doesn't interrupt redisplay at all. the above describes what happens when redisplay-dont-pause is nil.) As for the user lifting the finger, this is not the problem. Auto-repeat still sends one key at a time, with some time interval between the keys. As long as that interval is long enough for Emacs to compute the beginning of the window due to PageDown (and how long could that be?), Emacs will attempt to redisplay before the next repeated key arrives. > What is stopping a fragment of each intermediate screen (or of some of > them) being displayed? Could it be that the display engine calculates an > entire screenful of glyphs before it starts displaying them on the > physical screen? Emacs first calculates the minimum portion of the screen that needs redrawing (checking for input several times during this part, and abandoning redisplay if there's input and redisplay-dont-pause is nil). When these calculations are finished, it checks for input one last time. If there's no input, or if redisplay-dont-pause is non-nil, Emacs proceeds to actually drawing the parts that changed, and redraws all that is needed without any further input checks. Otherwise, the redisplay cycle is aborted. This is done for every frame at least, perhaps even for each window (I don't remember).