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 12:29:11 +0200 Message-ID: <83k3bn6e14.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> <532C0B9A.8050800@gmx.at> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1395397742 32695 80.91.229.3 (21 Mar 2014 10:29:02 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 21 Mar 2014 10:29:02 +0000 (UTC) Cc: cloos@jhcloos.com, christian@defun.dk, monnier@iro.umontreal.ca, kanru@kanru.info, emacs-devel@gnu.org To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Mar 21 11:29:10 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 1WQwhJ-0000Te-T9 for ged-emacs-devel@m.gmane.org; Fri, 21 Mar 2014 11:29:10 +0100 Original-Received: from localhost ([::1]:51884 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WQwhJ-0005b8-FU for ged-emacs-devel@m.gmane.org; Fri, 21 Mar 2014 06:29:09 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58173) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WQwhB-0005Ss-Ta for emacs-devel@gnu.org; Fri, 21 Mar 2014 06:29:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WQwh7-0004n6-QM for emacs-devel@gnu.org; Fri, 21 Mar 2014 06:29:01 -0400 Original-Received: from mtaout25.012.net.il ([80.179.55.181]:35427) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WQwh7-0004l4-7X for emacs-devel@gnu.org; Fri, 21 Mar 2014 06:28:57 -0400 Original-Received: from conversion-daemon.mtaout25.012.net.il by mtaout25.012.net.il (HyperSendmail v2007.08) id <0N2S00C007K01V00@mtaout25.012.net.il> for emacs-devel@gnu.org; Fri, 21 Mar 2014 12:27:30 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout25.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N2S002WS7PTTFA0@mtaout25.012.net.il>; Fri, 21 Mar 2014 12:27:29 +0200 (IST) In-reply-to: <532C0B9A.8050800@gmx.at> 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.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:170702 Archived-At: > Date: Fri, 21 Mar 2014 10:51:22 +0100 > From: martin rudalics > CC: emacs-devel@gnu.org, christian@defun.dk, monnier@iro.umontreal.ca, > kanru@kanru.info, cloos@jhcloos.com > > >> But wasn't the whole idea of maintaining an "obscured" state to not > >> update the glyph matrices when a change occurs while the frame is > >> obscured but instead to wait until the frame gets exposed again? > > > > Maybe so, but then what exactly is the problem we are discussing here? > > If the current glyph matrices are not up to date, marking the frame > > "garbaged" is the only way to redisplay it. > > Pretty early in this thread you stated > > Not reproducible here, but I'm not on GNU/Linux with GTK+. > > and I proposed a fix to do on GNU/Linux what we do on Windows but Stefan > considered that too heavy because it sets a frame garbaged even when it > was only iconified for some short period and its contentes didn't change > at all. So Stefan committed another fix for GNU/Linux and now proposes > to backport a similar fix to Windows. And I can't tell much because the > semantics of "garbaged" are still eluding me. I think the solution to Stefan's concerns is to set some flag, perhaps the frame's redisplay flag, when we bump into an iconified frame inside redisplay_internal. And in fact we already do that: /* Build desired matrices, and update the display. If consider_all_windows_p is non-zero, do it for all windows on all frames. Otherwise do it for selected_window, only. */ if (consider_all_windows_p) { FOR_EACH_FRAME (tail, frame) XFRAME (frame)->updated_p = 0; propagate_buffer_redisplay (); FOR_EACH_FRAME (tail, frame) { struct frame *f = XFRAME (frame); ... if (FRAME_WINDOW_P (f) || FRAME_TERMCAP_P (f) || f == sf) { ... if (FRAME_VISIBLE_P (f) && !FRAME_OBSCURED_P (f)) redisplay_windows (FRAME_ROOT_WINDOW (f)); /* Remember that the invisible frames need to be redisplayed next time they're visible. */ else if (!REDISPLAY_SOME_P ()) f->redisplay = true; <<<<<<<<<<<<<<<<<<<<<<<<<<< So it is unclear to me why there are problems with such frames: their redisplay flag should already be set when the contents changed, and reset otherwise. So why do we need to change anything at all? A new frame starts with its garbaged flag set, so it should have been redrawn completely when it becomes visible the first time. If that flag is reset, the culprit might be in the code which resets that flag. Or maybe consider_all_windows_p is zero in this case. I guess some more debugging is in order, because I don't understand the problem. Also, I wonder if there are any real-life use cases that trigger this problem, because the original recipe sounds artificial to me.