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: Redisplay problems? Date: Thu, 20 Mar 2014 20:12:56 +0200 Message-ID: <83siqc7n87.fsf@gnu.org> References: <87ppljg4ti.fsf@kanru-mozilla.corp.tpe1.mozilla.com> <5329C53B.3030008@gmx.at> <532ABA60.7000003@gmx.at> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=shift_jis Content-Transfer-Encoding: QUOTED-PRINTABLE X-Trace: ger.gmane.org 1395339170 10746 80.91.229.3 (20 Mar 2014 18:12:50 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 20 Mar 2014 18:12:50 +0000 (UTC) Cc: rudalics@gmx.at, christian@defun.dk, kanru@kanru.info, cloos@jhcloos.com, emacs-devel@gnu.org To: Stefan Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Mar 20 19:12:58 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 1WQhSb-0008Vs-SH for ged-emacs-devel@m.gmane.org; Thu, 20 Mar 2014 19:12:58 +0100 Original-Received: from localhost ([::1]:48621 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WQhSb-00006S-6P for ged-emacs-devel@m.gmane.org; Thu, 20 Mar 2014 14:12:57 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45881) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WQhSU-00006I-Uo for emacs-devel@gnu.org; Thu, 20 Mar 2014 14:12:55 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WQhSP-0004fa-3w for emacs-devel@gnu.org; Thu, 20 Mar 2014 14:12:50 -0400 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:60585) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WQhSO-0004fO-Rv for emacs-devel@gnu.org; Thu, 20 Mar 2014 14:12:45 -0400 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0N2Q00C00YD8L400@a-mtaout20.012.net.il> for emacs-devel@gnu.org; Thu, 20 Mar 2014 20:12:43 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N2Q00CFTYL6C560@a-mtaout20.012.net.il>; Thu, 20 Mar 2014 20:12:42 +0200 (IST) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.166 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:170645 Archived-At: > From: Stefan > Date: Thu, 20 Mar 2014 08:45:59 -0400 > Cc: Christian Lynbech , James Cloos , > =09Kan-Ru Chen (=92=C2=8A=A4=94@) , > =09emacs-devel@gnu.org >=20 > And of course, the frame's "garbaged" bit may not always be needed:= if > the frame was simply iconified+deiconified without any other change= , > there's no need to recompute matrices nor redraw anything, since it= 's > pretty much the same as obscuring the frame with another and then > exposing it again. But exposing does require a kind of "redrawing", see below. > I'm not 100% clear either, but my current understanding is that > "garbaged" means that the frame needs to be fully redrawn in the > following sense: >=20 > Normal redisplay takes place by first computing new matrices, then > comparing the old matrices to the new matrices to discover what nee= ds to > be changed on screen, then redrawing the parts that have changed. Your description is slightly inaccurate, and on top of that, you use several keywords in confusingly overloaded senses, which makes this discussion harder to understand. So allow me first to set the stage by making the description more accurate. Redisplay includes 2 phases. In the first phase, Emacs computes, for every window, the desired glyph matrix, which describes what should b= e on the display. This stage includes some redisplay optimizations, which can decide that certain portions of the display couldn't possibly have changed, in which case the corresponding parts ("glyph rows") of the desired matrix are marked "disabled". In the second phase of redisplay, Emacs compares the desired matrix with the "current matrix" (which was the desired matrix during the previous redisplay cycle). This stage also includes optimizations, but of a different kind. For each screen line, which corresponds to = a glyph row, Emacs redraws only the parts of that glyph row that are different from the corresponding row of the current matrix, and it also reuses what's on display as much as possible, even if they don't match exactly. Crucially, if the current matrix' glyph row is "disabled", the corresponding screen line is redrawn in its entirety. (If the desire= d matrix' glyph row is "disabled", it is simply copied to the current matrix without redrawing the line.) When Emacs decides that some part of a glyph row needs to be redrawn, it calls a function named draw_glyphs, which actually delivers the glyphs to the glass by calling the display-specific back-end (xterm.c etc.), after arranging the row's glyphs in "glyph strings", which mak= e the job easier for the back end. > So "garbaged" means that we should not try to only redraw the parts= that > have changed. When redisplay finds that a frame is "garbaged", it marks all of its glyph matrix rows "disabled". This will force their complete redrawing, as described above. > Note that the drawing that takes place in response to Expose events= is > not a "redraw": "redraw" is when a change inside Emacs causes a nee= d to > change the display, whereas expose events are due to changes outsid= e > of Emacs. An expose event calls expose_frame, which walks the frame's window tree, and redraws the part of each window that belongs to the exposed rectangle. This doesn't compute the glyph matrices at all, but just calls draw_glyphs directly to redraw the portions of the glyph rows that were exposed. IOW, the existing current glyph matrix is used without recomputing it. > Part of the reason it's still fuzzy is that xdisp.c seems to recomp= ute > the matrices when it finds a "garbaged" frame, so it seems that it > doesn't just cause it to "redraw". I have the impression that this= is > a mistake in that it's more work than needed, and also in that some= code > relies on that behavior (i.e. it sets the bit to cause a complete > redisplay+redraw). I don't think I understand what you meant to say here. But if you were talking about what to do about a frame that was deiconified, I think you need to call expose_frame, and arrange for the exposed rectangle to cover the entire frame. That should do what you want, n= o more, no less.