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 10:01:17 -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 1395324091 3846 80.91.229.3 (20 Mar 2014 14:01:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 20 Mar 2014 14:01:31 +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 15:01:38 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 1WQdXN-00084O-0v for ged-emacs-devel@m.gmane.org; Thu, 20 Mar 2014 15:01:37 +0100 Original-Received: from localhost ([::1]:47176 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WQdXM-0003Du-BX for ged-emacs-devel@m.gmane.org; Thu, 20 Mar 2014 10:01:36 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34051) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WQdXC-0002ru-Eb for emacs-devel@gnu.org; Thu, 20 Mar 2014 10:01:33 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WQdX5-00043r-3p for emacs-devel@gnu.org; Thu, 20 Mar 2014 10:01:26 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:35201) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WQdX5-00043h-07 for emacs-devel@gnu.org; Thu, 20 Mar 2014 10:01:19 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABK/CFHO+KKg/2dsb2JhbABEuzWDWRdzgh4BAQQBJy8jBQsLNBIUGA0kiB4GwS2RCgOOGJZigV6DEw X-IPAS-Result: Av8EABK/CFHO+KKg/2dsb2JhbABEuzWDWRdzgh4BAQQBJy8jBQsLNBIUGA0kiB4GwS2RCgOOGJZigV6DEw X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="52751864" 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 10:01:17 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 2B44E6012B; Thu, 20 Mar 2014 10:01:17 -0400 (EDT) In-Reply-To: (Stefan's message of "Thu, 20 Mar 2014 08:45:59 -0400") 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:170617 Archived-At: > 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. I suggest the patch below for w32term.c. Guaranteed 100% untested, of course, Stefan === modified file 'src/w32term.c' --- src/w32term.c 2014-03-14 10:38:46 +0000 +++ src/w32term.c 2014-03-20 13:55:14 +0000 @@ -4184,8 +4184,8 @@ if (f) { - if (msg.rect.right == msg.rect.left || - msg.rect.bottom == msg.rect.top) + if (msg.rect.right == msg.rect.left + || msg.rect.bottom == msg.rect.top) { /* We may get paint messages even though the client area is clipped - these are not expose events. */ @@ -4199,7 +4199,6 @@ /* Definitely not obscured, so mark as visible. */ SET_FRAME_VISIBLE (f, 1); SET_FRAME_ICONIFIED (f, 0); - SET_FRAME_GARBAGED (f); if (!f->output_data.w32->asked_for_visible) DebPrint (("frame %p (%s) reexposed by WM_PAINT\n", f, SDATA (f->name))); @@ -4444,8 +4443,9 @@ #if 0 /* The below is an invalid comparison when CHECK_LISP_OBJECT_TYPE. But it was originally changed to this to fix a bug, so I have not removed it completely in case the bug is still there. */ - if (help_echo_string != previous_help_echo_string || - (!NILP (help_echo_string) && !STRINGP (help_echo_string) && f->mouse_moved)) + if (help_echo_string != previous_help_echo_string + || (!NILP (help_echo_string) && !STRINGP (help_echo_string) + && f->mouse_moved)) #else /* This is what xterm.c does. */ if (!NILP (help_echo_string) || !NILP (previous_help_echo_string)) @@ -4557,8 +4557,8 @@ case WM_VSCROLL: { - struct scroll_bar *bar = - x_window_to_scroll_bar ((HWND)msg.msg.lParam); + struct scroll_bar *bar + = x_window_to_scroll_bar ((HWND)msg.msg.lParam); if (bar) w32_scroll_bar_handle_click (bar, &msg, &inev); @@ -4645,8 +4645,9 @@ SET_FRAME_VISIBLE (f, 1); SET_FRAME_ICONIFIED (f, 0); - /* wait_reading_process_output will notice this - and update the frame's display structures. */ + /* FIXME: We should not need to set `garbaged' if the + window was simply deiconified and it was previously + maximized. */ SET_FRAME_GARBAGED (f); if (iconified) @@ -4692,8 +4693,9 @@ SET_FRAME_VISIBLE (f, 1); SET_FRAME_ICONIFIED (f, 0); - /* wait_reading_process_output will notice this - and update the frame's display structures. */ + /* FIXME: We should not need to set `garbaged' if the + window was simply deiconified and it had previously + the same size. */ SET_FRAME_GARBAGED (f); if (iconified) @@ -4990,7 +4992,6 @@ if (obscured) { - SET_FRAME_GARBAGED (f); DebPrint (("obscured frame %p (%s) found to be visible\n", f, SDATA (f->name)));