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: Fri, 21 Mar 2014 18:12:24 +0200 Message-ID: <83eh1v5y53.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> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1395418340 32591 80.91.229.3 (21 Mar 2014 16:12:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 21 Mar 2014 16:12:20 +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 Fri Mar 21 17:12:27 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 1WR23T-0006ho-7H for ged-emacs-devel@m.gmane.org; Fri, 21 Mar 2014 17:12:23 +0100 Original-Received: from localhost ([::1]:53674 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WR23S-0003xz-Nh for ged-emacs-devel@m.gmane.org; Fri, 21 Mar 2014 12:12:22 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45903) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WR23K-0003wl-Sj for emacs-devel@gnu.org; Fri, 21 Mar 2014 12:12:18 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WR23G-0004Ke-Oe for emacs-devel@gnu.org; Fri, 21 Mar 2014 12:12:14 -0400 Original-Received: from mtaout21.012.net.il ([80.179.55.169]:65446) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WR23G-0004KW-GF for emacs-devel@gnu.org; Fri, 21 Mar 2014 12:12:10 -0400 Original-Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0N2S00000NCZBU00@a-mtaout21.012.net.il> for emacs-devel@gnu.org; Fri, 21 Mar 2014 18:12:09 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N2S00087NO8BC40@a-mtaout21.012.net.il>; Fri, 21 Mar 2014 18:12:08 +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.169 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:170720 Archived-At: > From: Stefan > Cc: rudalics@gmx.at, christian@defun.dk, kanru@kanru.info, cloos@jhcloos.com, emacs-devel@gnu.org > Date: Fri, 21 Mar 2014 08:59:37 -0400 > > > When the display is messed up (for some value of "messed up"), we > > cannot trust the current glyph matrices anymore. > > It all depends on the reason for the "messed up". E.g. it can be messed > up because some code drew something on screen without going through > "change matrices and reflect that change on screen". Emacs doesn't (and cannot) do that, AFAIK. But maybe I misunderstand what you mean. > That's what I would understand as the "natural meaning" for > "garbaged" (and in that case the matrices might still be trusted to > reflect "what we'd like to see on screen"). I didn't say it was natural, I tried to explain what it does. > So, IIUC this "natural meaning" is wrong. And "garbaged" is really > meant to say "disable all optimizations". If you include "smart" redrawing in optimizations, then yes, you could say that. > Which then begs the question: what is the difference with > `prevent_redisplay_optimizations_p'? That one only prevents optimizations in computing the desired matrices, AFAIR. It has no effect on actual redrawing in update_frame. > > I'm not an expert on those parts of Emacs, but it looks to me that we > > don't consistently call expose_frame when a frame is deiconified. > > Indeed and I think that's right because the expose_frame calls will be > performed later in response to expose events. Where do you see expose_frame called in response to expose events? That's what I didn't see.