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: Fri, 21 Mar 2014 09:37:24 +0200 Message-ID: <83a9ck6lzf.fsf@gnu.org> References: <87ppljg4ti.fsf@kanru-mozilla.corp.tpe1.mozilla.com> <5329C53B.3030008@gmx.at> <532ABA60.7000003@gmx.at> <83siqc7n87.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1395387433 12230 80.91.229.3 (21 Mar 2014 07:37:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 21 Mar 2014 07:37:13 +0000 (UTC) Cc: rudalics@gmx.at, christian@defun.dk, cloos@jhcloos.com, kanru@kanru.info, emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Mar 21 08:37:21 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 1WQu12-0007ZQ-V5 for ged-emacs-devel@m.gmane.org; Fri, 21 Mar 2014 08:37:21 +0100 Original-Received: from localhost ([::1]:51085 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WQu12-0001kc-HQ for ged-emacs-devel@m.gmane.org; Fri, 21 Mar 2014 03:37:20 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43387) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WQu0w-0001gA-Jk for emacs-devel@gnu.org; Fri, 21 Mar 2014 03:37:18 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WQu0s-0003Gb-G9 for emacs-devel@gnu.org; Fri, 21 Mar 2014 03:37:14 -0400 Original-Received: from mtaout26.012.net.il ([80.179.55.182]:34655) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WQu0s-0003GS-3R for emacs-devel@gnu.org; Fri, 21 Mar 2014 03:37:10 -0400 Original-Received: from conversion-daemon.mtaout26.012.net.il by mtaout26.012.net.il (HyperSendmail v2007.08) id <0N2R00300Z95LS00@mtaout26.012.net.il> for emacs-devel@gnu.org; Fri, 21 Mar 2014 09:36:18 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout26.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N2R00092ZSIOU60@mtaout26.012.net.il>; Fri, 21 Mar 2014 09:36:18 +0200 (IST) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 80.179.55.182 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:170683 Archived-At: > From: Stefan Monnier > Date: Thu, 20 Mar 2014 16:55:52 -0400 > Cc: rudalics@gmx.at, christian@defun.dk, kanru@kanru.info, cloos@jhcloos.com, > emacs-devel@gnu.org > > >> 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. > > Right, but that's not how "garbaged" is described (e.g. in the comment > before it: "True if this frame should be redrawn"), hence the fuzzyness. I never said your fuzzyness is not justified. That's why I described how things really work. > The way I see it described, "garbaged" means that the display is not in > sync with the matrices any more, but not that the matrices need to > be recomputed. > > But the implementation you describe here implies that "garbaged" will > end up recomputing all the matrices. When the display is messed up (for some value of "messed up"), we cannot trust the current glyph matrices anymore. Another situation is frame resize: then we _know_ the current matrices are useless. In these cases, we must redisplay everything, which must start from computing the desired glyph matrices. IOW, Emacs has no way of performing redisplay, except by computing the desired matrices -- these tell what should be on the screen. The commentary describes the effect of the "garbaged" flag (eventually, the frame will indeed be redrawn in its entirety), but it does not describe the implementation of causing that effect. > And in turn I suspect some of the code takes advantage of the knowledge > of how "garbaged" is implemented: it sets "garbaged" to cause the > matrices to be recomputed (and the frame redrawn redrawn). As I described, the desired matrices are _always_ recomputed, if we enter redisplay through redisplay_internal. (Expose events bypass that stage.) So there's no need to cause the matrices to be recomputed: they always will be. What you can do is disable the optimizations that might allow Emacs to recompute only some portions of the desired matrices. We currently do that by setting windows_or_buffers_changed (via fset_redisplay that calls redisplay_other_windows), when the frame's "garbaged" flag is set. This disabling of redisplay optimizations is inevitable when the current matrices cannot be used for comparison with desired ones. But if you only want to cause a full re-computation of all the desired matrices, all you need to do is set windows_or_buffers_changed. Note, however, that doing that without also setting the frame's "garbaged" flag might end up redrawing very little, or nothing at all, if the recomputed desired matrices are found to be similar or identical to the current one. Only setting the "garbaged" flag ensures we will actually redraw the entire frame, i.e. refresh what's on the glass. > > 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, no > > more, no less. > > Doesn't the windowing-system do that already for us? If you mean that it somehow magically calls expose_frame, then no, I don't think so. We should call it ourselves when the right event(s) come(s). I'm not an expert on those parts of Emacs, but it looks to me that we don't consistently call expose_frame when a frame is deiconified. I might be mistaken, though. Also note that setting the "garbaged" flag makes expose_frame a no-op: it immediately returns without doing anything, because it knows the frame will be completely redrawn very soon.