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 18:58:36 +0200 Message-ID: <83ob0v1qkj.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> <877g7kxai3.fsf@fencepost.gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1395680339 16270 80.91.229.3 (24 Mar 2014 16:58:59 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 24 Mar 2014 16:58:59 +0000 (UTC) Cc: emacs-devel@gnu.org To: David Kastrup Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Mar 24 17:59:08 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 1WS8DK-0008Kp-7n for ged-emacs-devel@m.gmane.org; Mon, 24 Mar 2014 17:59:06 +0100 Original-Received: from localhost ([::1]:37543 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WS8DJ-00060X-VK for ged-emacs-devel@m.gmane.org; Mon, 24 Mar 2014 12:59:05 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49381) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WS8DE-0005zS-3V for emacs-devel@gnu.org; Mon, 24 Mar 2014 12:59:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WS8D9-0005FF-Vx for emacs-devel@gnu.org; Mon, 24 Mar 2014 12:59:00 -0400 Original-Received: from mtaout24.012.net.il ([80.179.55.180]:48686) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WS8D2-0005BU-Rr; Mon, 24 Mar 2014 12:58:49 -0400 Original-Received: from conversion-daemon.mtaout24.012.net.il by mtaout24.012.net.il (HyperSendmail v2007.08) id <0N2Y00G00989Z300@mtaout24.012.net.il>; Mon, 24 Mar 2014 18:56:42 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout24.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N2Y0093P9QHAA70@mtaout24.012.net.il>; Mon, 24 Mar 2014 18:56:42 +0200 (IST) In-reply-to: <877g7kxai3.fsf@fencepost.gnu.org> 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:170915 Archived-At: > From: David Kastrup > Date: Mon, 24 Mar 2014 09:32:20 +0100 > > Eli Zaretskii writes: > > >> From: Stefan > >> Cc: rudalics@gmx.at, christian@defun.dk, kanru@kanru.info, cloos@jhcloos.com, > >> emacs-devel@gnu.org > >> Date: Sun, 23 Mar 2014 21:58:32 -0400 > >> > >> > I actually don't think we should be bothered about this at all. Why > >> > does it make sense to optimize the use case where a frame is > >> > deiconified? > >> > >> If you have 50 frames, 25 on one desktop and 25 on the other, whenever > >> you switch from one desktop to the other, 25 frames get deiconified and > >> the other 25 get iconified. > > > > I still don't see anything performance critical even in this scenario. > > A switch to a different desktop is not something one would do several > > times a second, and it's okay for it to take a second or so. > > It is quite customary to _cycle_ through desktops and go through several > in fast succession until finding the desired one. Most certainly at a > rate of several (three or four) per second. You took what I wrote too literally, I think. What you describe deiconifies frames at higher rate, but only momentarily so. Once the desired desktop is located, the user will stay with it for some time, until she again switches. So I still see no reason to regard this as performance critical. OTOH, when we need to deiconify a frame, or expose a large portion of it, I see no space for significant optimizations anyway. Redisplay optimizations are about redrawing as small portions of the frame as possible. But in the case in point, we basically need to redraw the entire frame -- how much can you win here anyway?