From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.devel Subject: Re: Redisplay problems? Date: Thu, 20 Mar 2014 20:22:38 +0100 Message-ID: <532B3FFE.5020403@gmx.at> 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; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1395343395 31429 80.91.229.3 (20 Mar 2014 19:23:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 20 Mar 2014 19:23:15 +0000 (UTC) Cc: Christian Lynbech , James Cloos , =?UTF-8?B?Ikthbi1SdSBDaGVuICjpmbPkvoPlpoIpIg==?= , emacs-devel@gnu.org To: Stefan Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Mar 20 20:23:21 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 1WQiYh-0004eT-NH for ged-emacs-devel@m.gmane.org; Thu, 20 Mar 2014 20:23:19 +0100 Original-Received: from localhost ([::1]:48909 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WQiYg-0000Ox-MV for ged-emacs-devel@m.gmane.org; Thu, 20 Mar 2014 15:23:18 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33100) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WQiYX-0000OD-Jm for emacs-devel@gnu.org; Thu, 20 Mar 2014 15:23:16 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WQiYQ-0003eV-A5 for emacs-devel@gnu.org; Thu, 20 Mar 2014 15:23:09 -0400 Original-Received: from mout.gmx.net ([212.227.17.20]:56787) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WQiYQ-0003Zv-0H for emacs-devel@gnu.org; Thu, 20 Mar 2014 15:23:02 -0400 Original-Received: from [188.22.40.199] ([188.22.40.199]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0Lurin-1X8XqS2tw9-0104ud; Thu, 20 Mar 2014 20:22:49 +0100 In-Reply-To: X-Provags-ID: V03:K0:eloSezgJnNEIf8Wouzg5LuaLJxR+sBK6ugazFu3UuphgYMEXsXO Kw5+hKWfya7pnOZAaJKVQnoB215jXkqyVMH4ZzfFaTgA0meP+9hVI0ZeJqQeQ/sUhI0sQ+O VETq/iXDnERAVfp+yx7NK31p3CjwDFu3N8GxR+ufFivfDWmVhJJJ8574znyI7wN4U72Ft86 nmv3ppeefNotNis9mY8hA== X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 212.227.17.20 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:170654 Archived-At: > 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). OK. But the major issue is to prevent a frame's contents to stay blank forever (unless the user intervenes in some way or the other). > 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. Yes, that's the main difference. But it requires to carefully keep track of changes via the `garbaged' slot. > I'm not 100% clear either, but my current understanding is that > "garbaged" means that the frame needs to be fully redrawn ... where "fully" means all windows? > 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. I'm not sure I follow you here. If we do a resize of the frame we may need larger matrices so we tell the display engine via the resized_p slot. If a change is restricted to a certain buffer or window only, we can tell the display engien which one is affected. Other from that what kind of guidance can you possibly give to the display engine? > 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. But it's a redraw when we expose a hitherto invisible/obscured frame whose contents have changed while it was invisible/obscured. > Part of the reason it's still fuzzy is that xdisp.c seems to recompute > the matrices when it finds a "garbaged" frame, But we do have to compute the new matrices to know whether they have changed. I'm fully confused now. > 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). What is the "less work" that's needed? martin