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: Mon, 24 Mar 2014 14:07:34 -0400 Message-ID: References: <532ABA60.7000003@gmx.at> <83siqc7n87.fsf@gnu.org> <83a9ck6lzf.fsf@gnu.org> <83eh1v5y53.fsf@gnu.org> <83y5024r1w.fsf@gnu.org> <83ior6489a.fsf@gnu.org> <834n2q43os.fsf@gnu.org> <83vbv62gr7.fsf@gnu.org> <83txao1c8n.fsf@gnu.org> <83k3bj1otm.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1395684482 32360 80.91.229.3 (24 Mar 2014 18:08:02 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 24 Mar 2014 18:08:02 +0000 (UTC) Cc: rudalics@gmx.at, christian@defun.dk, cloos@jhcloos.com, kanru@kanru.info, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Mar 24 19:08: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 1WS9I9-00054G-Px for ged-emacs-devel@m.gmane.org; Mon, 24 Mar 2014 19:08:09 +0100 Original-Received: from localhost ([::1]:37830 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WS9I9-0006gv-Bw for ged-emacs-devel@m.gmane.org; Mon, 24 Mar 2014 14:08:09 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37894) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WS9Hz-0006gW-0i for emacs-devel@gnu.org; Mon, 24 Mar 2014 14:08:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WS9Ho-0004Kx-Sn for emacs-devel@gnu.org; Mon, 24 Mar 2014 14:07:58 -0400 Original-Received: from chene.dit.umontreal.ca ([132.204.246.20]:35742) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WS9Ho-0004Jk-OM; Mon, 24 Mar 2014 14:07:48 -0400 Original-Received: from pastel.home (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id s2OI7rFW016112; Mon, 24 Mar 2014 14:07:53 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id D29AF6012F; Mon, 24 Mar 2014 14:07:34 -0400 (EDT) In-Reply-To: <83k3bj1otm.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 24 Mar 2014 19:36:21 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV4891=0 X-NAI-Spam-Version: 2.3.0.9362 : core <4891> : inlines <637> : streams <1143952> : uri <1708665> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 132.204.246.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:170923 Archived-At: > (Btw, what about parallel redisplaying of several frames by several > independent threads?) Patch welcome. > However, what I wrote was only about deiconifying a frame, or > redrawing a frame which was entirely obscured. If we are still > talking about that case, please tell more about the situations where > deiconifying a frame was a bottleneck or even a significant annoyance. Occasionally, closing a large frame that obscured a dozen frames underneath could be such a problem, but since in X11 we don't optimize "obscured" like we do under w32 I haven't noticed it. In any case, Emacs can't tell the difference between "switching workspace" and "deiconifying", AFAIK. > How to do that is another question. Blindly assuming that the current > matrices are up to date doesn't sound like a good idea to me: we will > momentarily flash incorrect display, and sooner or later people will > complain. And such an incorrect redisplay will be immediately > followed another one, so what exactly have we gained? In case the next redisplay is far away, it's better to display the old window's content than to leave "garbage" on the screen, I think. I don't think it's a very serious issue either way. But the code had a comment specifically mentioning that we preferred not setting the `garbaged' flag (when possible) so as to avoid a blank/undraw frame being displayed if a frame is deiconified while we're in the middle of a toolkit menu. > But we could do this when the redisplay flag of the frame is not set, > for example. We could, yes. But I'm not sure it would really be better. > If the redisplay flag of an obscured/iconified frame _is_ set, then it > looks like you cannot win anyway, because the entire frame needs to be > completely redisplayed, and comparing against the current matrices is > meaningless (since nothing is on the glass, so a full redraw is the > only alternative). So I think setting the garbaged flag in this case > is TRT. No: setting the garbaged flag has the side-effect of disabling all optimizations while computing the new matrices. And in this case, we don't need to disable those optimizations, AFAIK. Stefan