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: Sat, 22 Mar 2014 21:08:28 +0200 Message-ID: <83vbv62gr7.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> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1395515319 11396 80.91.229.3 (22 Mar 2014 19:08:39 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 22 Mar 2014 19:08:39 +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 Sat Mar 22 20:08: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 1WRRHj-0004xT-5a for ged-emacs-devel@m.gmane.org; Sat, 22 Mar 2014 20:08:47 +0100 Original-Received: from localhost ([::1]:57908 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WRRHi-0001Fe-Na for ged-emacs-devel@m.gmane.org; Sat, 22 Mar 2014 15:08:46 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48774) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WRRHc-0001FL-4m for emacs-devel@gnu.org; Sat, 22 Mar 2014 15:08:44 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WRRHY-0000kn-2L for emacs-devel@gnu.org; Sat, 22 Mar 2014 15:08:40 -0400 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:51383) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WRRHX-0000jr-QB for emacs-devel@gnu.org; Sat, 22 Mar 2014 15:08:35 -0400 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0N2U00F00QDEQY00@a-mtaout22.012.net.il> for emacs-devel@gnu.org; Sat, 22 Mar 2014 21:08:34 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N2U00FFMQI9ND30@a-mtaout22.012.net.il>; Sat, 22 Mar 2014 21:08:34 +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.172 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:170811 Archived-At: > From: Stefan > Cc: rudalics@gmx.at, christian@defun.dk, kanru@kanru.info, cloos@jhcloos.com, > emacs-devel@gnu.org > Date: Sat, 22 Mar 2014 14:43:21 -0400 > > > When frames that were iconified get the expose event, and the frame's > > garbaged flag is not set, we will redraw them using outdated matrices, > > because expose_frame uses the current glyph matrices without > > recomputing them. > > If the current matrices are outdated, then indeed we may expose the > outdated content. But of course, the next redisplay will fix it, so > it's not terrible. You will momentarily show incorrect contents. > If the garbaged flag is set, the behavior is not much better: instead of > exposing outdated content we don't expose anything (i.e. it stays > blank), and again the next redisplay should fix. It is slightly better, because you never show incorrect contents. > This said, I think that the more common case of deiconifying/deobscuring > is that the matrices are still up-to-date because nothing has changed in > the mean time. In that case we're better off not setting the "garbaged" > flag, so we immediately get the right content exposed rather then first > exposing blank. 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?