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 18:19:02 +0200 Message-ID: <83bnwz5xu1.fsf@gnu.org> References: <87ppljg4ti.fsf@kanru-mozilla.corp.tpe1.mozilla.com> <5329C53B.3030008@gmx.at> <532ABA60.7000003@gmx.at> <532B3FFE.5020403@gmx.at> <83eh1w7gkd.fsf@gnu.org> <532BF25B.2070004@gmx.at> <83siqc54nv.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1395418731 5409 80.91.229.3 (21 Mar 2014 16:18:51 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 21 Mar 2014 16:18:51 +0000 (UTC) Cc: rudalics@gmx.at, christian@defun.dk, cloos@jhcloos.com, kanru@kanru.info, emacs-devel@gnu.org To: Stefan Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Mar 21 17:19:00 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 1WR29r-0007L0-SD for ged-emacs-devel@m.gmane.org; Fri, 21 Mar 2014 17:18:59 +0100 Original-Received: from localhost ([::1]:53708 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WR29r-0005nH-CJ for ged-emacs-devel@m.gmane.org; Fri, 21 Mar 2014 12:18:59 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47163) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WR29l-0005mK-I4 for emacs-devel@gnu.org; Fri, 21 Mar 2014 12:18:57 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WR29g-0006SP-Az for emacs-devel@gnu.org; Fri, 21 Mar 2014 12:18:53 -0400 Original-Received: from mtaout29.012.net.il ([80.179.55.185]:33588) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WR29g-0006SJ-2k for emacs-devel@gnu.org; Fri, 21 Mar 2014 12:18:48 -0400 Original-Received: from conversion-daemon.mtaout29.012.net.il by mtaout29.012.net.il (HyperSendmail v2007.08) id <0N2S00300O1XRX00@mtaout29.012.net.il> for emacs-devel@gnu.org; Fri, 21 Mar 2014 18:21:40 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout29.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N2S00J71O44H9A0@mtaout29.012.net.il>; Fri, 21 Mar 2014 18:21:40 +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.185 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:170722 Archived-At: > From: Stefan > Cc: martin rudalics , kanru@kanru.info, christian@defun.dk, cloos@jhcloos.com, emacs-devel@gnu.org > Date: Fri, 21 Mar 2014 09:08:02 -0400 > > > If the current glyph matrices are not up to date, marking the frame > > "garbaged" is the only way to redisplay it. > > No: the next redisplay will update the glyph matrices just fine without > having to set `garbaged'. This is true (except that only parts of the matrices might be recomputed, which might not be what you want), but computing the desired glyph matrices when the current matrices cannot be used for comparison is simply useless, because Emacs will be unable to redraw the modified parts correctly. For redrawing, Emacs must either (1) have current matrices it can trust, or (2) assume the current matrices are useful, and use the desired matrices to redraw everything. The latter alternative is what the garbaged flag triggers. > And the portions of the frame made visible by > unobscuring/deiconifying will be redrawn in response to the expose > events that windowing-system will send us. That is only possible if the current matrices of the frame correctly reflect what should be on the screen, because expose_frame uses the current matrices without recomputing them. > > I guess some more debugging is in order, because I don't understand > > the problem. > > AFAIK there is no problem (other than people trying to understand > why/how things work). If we don't understand how things work, how can we be sure we fixed the bug?