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: Thu, 20 Mar 2014 22:36:50 +0200 Message-ID: <83eh1w7gkd.fsf@gnu.org> References: <87ppljg4ti.fsf@kanru-mozilla.corp.tpe1.mozilla.com> <5329C53B.3030008@gmx.at> <532ABA60.7000003@gmx.at> <532B3FFE.5020403@gmx.at> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE X-Trace: ger.gmane.org 1395347805 21564 80.91.229.3 (20 Mar 2014 20:36:45 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 20 Mar 2014 20:36:45 +0000 (UTC) Cc: kanru@kanru.info, christian@defun.dk, monnier@iro.umontreal.ca, cloos@jhcloos.com, emacs-devel@gnu.org To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Mar 20 21:36:53 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 1WQjhs-000288-Kt for ged-emacs-devel@m.gmane.org; Thu, 20 Mar 2014 21:36:52 +0100 Original-Received: from localhost ([::1]:49187 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WQjhs-0007ll-2g for ged-emacs-devel@m.gmane.org; Thu, 20 Mar 2014 16:36:52 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48652) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WQjhk-0007lS-Fv for emacs-devel@gnu.org; Thu, 20 Mar 2014 16:36:48 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WQjhe-00034K-3Z for emacs-devel@gnu.org; Thu, 20 Mar 2014 16:36:44 -0400 Original-Received: from mtaout24.012.net.il ([80.179.55.180]:53985) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WQjhd-000347-MO for emacs-devel@gnu.org; Thu, 20 Mar 2014 16:36:38 -0400 Original-Received: from conversion-daemon.mtaout24.012.net.il by mtaout24.012.net.il (HyperSendmail v2007.08) id <0N2R00L004CX6O00@mtaout24.012.net.il> for emacs-devel@gnu.org; Thu, 20 Mar 2014 22:34:30 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout24.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N2R00EKT55HEEA0@mtaout24.012.net.il>; Thu, 20 Mar 2014 22:34:30 +0200 (IST) In-reply-to: <532B3FFE.5020403@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.180 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:170669 Archived-At: > Date: Thu, 20 Mar 2014 20:22:38 +0100 > From: martin rudalics > Cc: Christian Lynbech , James Cloos , > =09"Kan-Ru Chen (=E9=99=B3=E4=BE=83=E5=A6=82)" , > =09emacs-devel@gnu.org >=20 > > And of course, the frame's "garbaged" bit may not always be need= ed: if > > the frame was simply iconified+deiconified without any other cha= nge, > > there's no need to recompute matrices nor redraw anything, since= it's > > pretty much the same as obscuring the frame with another and the= n > > exposing it again. >=20 > Yes, that's the main difference. But it requires to carefully keep > track of changes via the `garbaged' slot. As I wrote elsewhere, I see no reason for marking such a frame "garbaged", because its glyph matrices are just fine. Unless you can show me some code that avoids recomputing or invalidating the matrice= s of an iconified frame. > > I'm not 100% clear either, but my current understanding is that > > "garbaged" means that the frame needs to be fully redrawn >=20 > ... where "fully" means all windows? Yes, all of them. The glyph matrices of all the windows of such a frame are invalidated by clear_garbaged_frames, which is called at th= e beginning of a redisplay cycle. > > Normal redisplay takes place by first computing new matrices, th= en > > 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 pa= rts that > ^^^ >=20 > > have changed. >=20 > I'm not sure I follow you here. I think Stefan wanted to say that "garbaged" means redraw more than just the parts that have changed. If you read my description, I explained that a "garbaged" frame means Emacs does not believe the contents of the current glyph matrices for that frame is reliable. So it discards them, and that forces a complete redraw of all the windows on the frame. > > Note that the drawing that takes place in response to Expose eve= nts 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 out= side > > of Emacs. >=20 > But it's a redraw when we expose a hitherto invisible/obscured fram= e > whose contents have changed while it was invisible/obscured. If the glyph matrices of such a frame were updated when the contents changed, then there's no need to recompute them at expose event time. > > Part of the reason it's still fuzzy is that xdisp.c seems to rec= ompute > > the matrices when it finds a "garbaged" frame, >=20 > But we do have to compute the new matrices to know whether they hav= e > changed. I'm fully confused now. Actually, the desired glyph matrices are always recomputed when we enter redisplay. But if the result is identical to the current matrix, then nothing is redrawn. When a frame is marked "garbaged", Emacs clears the current glyph matrices, so it loses the ability to optimize the redraw phase of the redisplay cycle, because there's nothing with which to compare the desired matrices.