From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Newsgroups: gmane.emacs.devel Subject: Re: Redisplay problems? Date: Thu, 20 Mar 2014 08:45:59 -0400 Message-ID: References: <87ppljg4ti.fsf@kanru-mozilla.corp.tpe1.mozilla.com> <5329C53B.3030008@gmx.at> <532ABA60.7000003@gmx.at> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1395319645 10314 80.91.229.3 (20 Mar 2014 12:47:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 20 Mar 2014 12:47:25 +0000 (UTC) Cc: Christian Lynbech , James Cloos , =?utf-8?B?S2FuLVJ1IENoZW4gKOmZs+S+g+Wmgik=?= , emacs-devel@gnu.org To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Mar 20 13:47:33 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 1WQcNg-0006xf-QG for ged-emacs-devel@m.gmane.org; Thu, 20 Mar 2014 13:47:33 +0100 Original-Received: from localhost ([::1]:46810 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WQcNg-0003l3-7n for ged-emacs-devel@m.gmane.org; Thu, 20 Mar 2014 08:47:32 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46160) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WQcMK-0000rJ-6a for emacs-devel@gnu.org; Thu, 20 Mar 2014 08:46:15 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WQcMC-0003qW-TP for emacs-devel@gnu.org; Thu, 20 Mar 2014 08:46:08 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:3146) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WQcMC-0003qR-PH for emacs-devel@gnu.org; Thu, 20 Mar 2014 08:46:00 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EABK/CFHO+KKg/2dsb2JhbABEvw4Xc4IeAQEEAScvFQ4QCzQSFBgNJIgeBsEtjQ6DfAOOGJZigV6DEw X-IPAS-Result: Av4EABK/CFHO+KKg/2dsb2JhbABEvw4Xc4IeAQEEAScvFQ4QCzQSFBgNJIgeBsEtjQ6DfAOOGJZigV6DEw X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="52744406" Original-Received: from 206-248-162-160.dsl.teksavvy.com (HELO pastel.home) ([206.248.162.160]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 20 Mar 2014 08:45:59 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 89BAB6012B; Thu, 20 Mar 2014 08:45:59 -0400 (EDT) In-Reply-To: <532ABA60.7000003@gmx.at> (martin rudalics's message of "Thu, 20 Mar 2014 10:52:32 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 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:170614 Archived-At: >> I think my patch indeed fixes this problem by distinguishing between >> f->garbaged (which presumably stops redrawing in Expose, tho I don't >> offhand see where that happens) and frame_garbaged (which is needed to >> get the next redisplay to be properly triggered and performed). > IIUC my earlier proposal to SET_FRAME_GARBAGED unconditionally subsumes > what you propose here because I set frame_garbaged and the garbaged slot > of the frame that received the MapNotify event. However, since I set > the garbaged slot unconditionally, your proposal provides a better check > as to whether we previously have set a frame's garbaged slot correctly. > Is that observation correct or am I missing something? Yes, tho I'm not sure I agree with "subsumes": according to the comment, setting more things "garbaged" may cause some frame's content to stay blank for a while (because Emacs is in the middle of something which prevents redisplay from taking place). 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. >> If it looks right, then we might reconsider the SET_FRAME_GARBAGED in >> w32term.c in light of such a change, but that's even further away from >> my expertise. > I'm still struggling with the semantics of what a "garbaged frame" is > and whether we always set the garbaged slot correctly. 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: Normal redisplay takes place by first computing new matrices, then comparing the old matrices to the new matrices to discover what needs to be changed on screen, then redrawing the parts that have changed. So "garbaged" means that we should not try to only redraw the parts that have changed. 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 need to change the display, whereas expose events are due to changes outside of Emacs. Part of the reason it's still fuzzy is that xdisp.c seems to recompute 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). Stefan