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: Mon, 24 Mar 2014 19:36:21 +0200 Message-ID: <83k3bj1otm.fsf@gnu.org> References: <87ppljg4ti.fsf@kanru-mozilla.corp.tpe1.mozilla.com> <5329C53B.3030008@gmx.at> <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> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1395682602 25429 80.91.229.3 (24 Mar 2014 17:36:42 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 24 Mar 2014 17:36:42 +0000 (UTC) Cc: rudalics@gmx.at, christian@defun.dk, cloos@jhcloos.com, kanru@kanru.info, emacs-devel@gnu.org To: Stefan Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Mar 24 18:36:47 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 1WS8nn-0001Ss-4E for ged-emacs-devel@m.gmane.org; Mon, 24 Mar 2014 18:36:47 +0100 Original-Received: from localhost ([::1]:37733 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WS8nm-0001u6-Lz for ged-emacs-devel@m.gmane.org; Mon, 24 Mar 2014 13:36:46 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58302) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WS8nf-0001o6-Nq for emacs-devel@gnu.org; Mon, 24 Mar 2014 13:36:43 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WS8nY-0001WN-To for emacs-devel@gnu.org; Mon, 24 Mar 2014 13:36:39 -0400 Original-Received: from mtaout23.012.net.il ([80.179.55.175]:56009) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WS8nY-0001WI-MT for emacs-devel@gnu.org; Mon, 24 Mar 2014 13:36:32 -0400 Original-Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0N2Y00G00BGI1000@a-mtaout23.012.net.il> for emacs-devel@gnu.org; Mon, 24 Mar 2014 19:36:31 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N2Y00FD9BKUW4A0@a-mtaout23.012.net.il>; Mon, 24 Mar 2014 19:36:31 +0200 (IST) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.175 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:170919 Archived-At: > From: Stefan > Cc: rudalics@gmx.at, christian@defun.dk, kanru@kanru.info, cloos@jhcloos.com, > emacs-devel@gnu.org > Date: Mon, 24 Mar 2014 08:33:30 -0400 > > > I still don't see anything performance critical even in this scenario. > > I lived with the older slower behavior for many years, indeed. > > But computers aren't getting very much faster and avoiding a rebuild of > the glyph matrices sped up some of my use cases significantly, making > the behavior noticeably smoother. On these general terms, we are in violent agreement. (Btw, what about parallel redisplaying of several frames by several independent threads?) 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. In any case, I'm not opposed to attempts to optimize these scenarios. 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? But we could do this when the redisplay flag of the frame is not set, for example. 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. IOW, the garbaged flag of an obscured or iconified frame should only be set after its redisplay flag is set. I don't see any place for further optimization; do you?