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 00:46:13 -0400 Message-ID: References: <87ppljg4ti.fsf@kanru-mozilla.corp.tpe1.mozilla.com> <5329C53B.3030008@gmx.at> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1395290783 11881 80.91.229.3 (20 Mar 2014 04:46:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 20 Mar 2014 04:46:23 +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 05:46:32 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 1WQUsB-0008Us-NN for ged-emacs-devel@m.gmane.org; Thu, 20 Mar 2014 05:46:31 +0100 Original-Received: from localhost ([::1]:45180 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WQUsB-0005Qk-CH for ged-emacs-devel@m.gmane.org; Thu, 20 Mar 2014 00:46:31 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54432) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WQUs2-0005Hk-9h for emacs-devel@gnu.org; Thu, 20 Mar 2014 00:46:29 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WQUru-0006I3-Sb for emacs-devel@gnu.org; Thu, 20 Mar 2014 00:46:22 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:7770) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WQUru-0006Hz-O3 for emacs-devel@gnu.org; Thu, 20 Mar 2014 00:46:14 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABK/CFHO+KKg/2dsb2JhbABEuzWDWRdzgh4BAQQBJy8VDgULCzQSFBgNJIgeBsEtkQoDjhiWYoFegxM X-IPAS-Result: Av8EABK/CFHO+KKg/2dsb2JhbABEuzWDWRdzgh4BAQQBJy8VDgULCzQSFBgNJIgeBsEtkQoDjhiWYoFegxM X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="52715730" 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 00:46:13 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 9D95160123; Thu, 20 Mar 2014 00:46:13 -0400 (EDT) In-Reply-To: <5329C53B.3030008@gmx.at> (martin rudalics's message of "Wed, 19 Mar 2014 17:26:35 +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:170599 Archived-At: > Does the attached patch fix it? The patch below seems to fix the problem (at least the test case). Can someone confirm that it's a good idea? > If so, we probably need a better way to avoid > > If we where iconified, we should not set garbaged, > because that stops redrawing on Expose events. This looks > bad if we are called from a recursive event loop > (x_dispatch_event), for example when a dialog is up. 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). 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. Stefan --- src/frame.h 2014-01-01 07:43:34 +0000 +++ src/frame.h 2014-03-20 04:30:42 +0000 @@ -946,6 +946,9 @@ } \ } while (false) +/* False means there are no visible garbaged frames. */ +extern bool frame_garbaged; + /* Set visibility of frame F. We call redisplay_other_windows to make sure the frame gets redisplayed if some changes were applied to it while it wasn't visible (and hence @@ -955,8 +958,13 @@ SET_FRAME_VISIBLE (struct frame *f, int v) { eassert (0 <= v && v <= 2); + if (v) + { if (v == 1 && f->visible != 1) redisplay_other_windows (); + if (FRAME_GARBAGED_P (f)) + frame_garbaged = true; + } f->visible = v; } @@ -972,9 +980,6 @@ extern Lisp_Object Qterminal; extern Lisp_Object Qnoelisp; -/* True means there is at least one garbaged frame. */ -extern bool frame_garbaged; - extern void set_menu_bar_lines (struct frame *, Lisp_Object, Lisp_Object); extern struct frame *decode_window_system_frame (Lisp_Object); extern struct frame *decode_live_frame (Lisp_Object); --- src/xterm.c 2014-03-11 06:50:01 +0000 +++ src/xterm.c 2014-03-20 04:28:16 +0000 @@ -6142,14 +6142,6 @@ if (f) { bool iconified = FRAME_ICONIFIED_P (f); - /* wait_reading_process_output will notice this and update - the frame's display structures. - If we where iconified, we should not set garbaged, - because that stops redrawing on Expose events. This looks - bad if we are called from a recursive event loop - (x_dispatch_event), for example when a dialog is up. */ - if (!iconified) - SET_FRAME_GARBAGED (f); /* Check if fullscreen was specified before we where mapped the first time, i.e. from the command line. */