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: Fri, 21 Mar 2014 08:59:37 -0400 Message-ID: References: <87ppljg4ti.fsf@kanru-mozilla.corp.tpe1.mozilla.com> <5329C53B.3030008@gmx.at> <532ABA60.7000003@gmx.at> <83siqc7n87.fsf@gnu.org> <83a9ck6lzf.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1395406971 15178 80.91.229.3 (21 Mar 2014 13:02:51 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 21 Mar 2014 13:02:51 +0000 (UTC) Cc: rudalics@gmx.at, christian@defun.dk, cloos@jhcloos.com, kanru@kanru.info, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Mar 21 14:02:57 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 1WQz67-0006v6-Oq for ged-emacs-devel@m.gmane.org; Fri, 21 Mar 2014 14:02:55 +0100 Original-Received: from localhost ([::1]:52699 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WQz67-0001sv-Do for ged-emacs-devel@m.gmane.org; Fri, 21 Mar 2014 09:02:55 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35177) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WQz3E-0006pi-Dj for emacs-devel@gnu.org; Fri, 21 Mar 2014 09:00:03 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WQz37-0007CS-4o for emacs-devel@gnu.org; Fri, 21 Mar 2014 08:59:56 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:55795) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WQz2w-00078I-EL; Fri, 21 Mar 2014 08:59:41 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EABK/CFHO+KKg/2dsb2JhbABEvw4Xc4IeAQEEAVYVDgULCzQSFBgNJIgeBsEtjQ6DfAOOGJZigV6DEw X-IPAS-Result: Av4EABK/CFHO+KKg/2dsb2JhbABEvw4Xc4IeAQEEAVYVDgULCzQSFBgNJIgeBsEtjQ6DfAOOGJZigV6DEw X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="52848961" 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; 21 Mar 2014 08:59:37 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 570BD60202; Fri, 21 Mar 2014 08:59:37 -0400 (EDT) In-Reply-To: <83a9ck6lzf.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 21 Mar 2014 09:37:24 +0200") 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:170709 Archived-At: > When the display is messed up (for some value of "messed up"), we > cannot trust the current glyph matrices anymore. It all depends on the reason for the "messed up". E.g. it can be messed up because some code drew something on screen without going through "change matrices and reflect that change on screen". That's what I would understand as the "natural meaning" for "garbaged" (and in that case the matrices might still be trusted to reflect "what we'd like to see on screen"). So, IIUC this "natural meaning" is wrong. And "garbaged" is really meant to say "disable all optimizations". Which then begs the question: what is the difference with `prevent_redisplay_optimizations_p'? >> > 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. No, I mean that the windowing-system should already arrange to send us the relevant expose events (which could be "no events at all", if the windowing system were to draw the frame from some backed up copy). > 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. Indeed and I think that's right because the expose_frame calls will be performed later in response to expose events. Stefan