From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Redisplay problems? Date: Thu, 20 Mar 2014 16:55:52 -0400 Message-ID: References: <87ppljg4ti.fsf@kanru-mozilla.corp.tpe1.mozilla.com> <5329C53B.3030008@gmx.at> <532ABA60.7000003@gmx.at> <83siqc7n87.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1395348999 5319 80.91.229.3 (20 Mar 2014 20:56:39 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 20 Mar 2014 20:56:39 +0000 (UTC) Cc: rudalics@gmx.at, christian@defun.dk, kanru@kanru.info, cloos@jhcloos.com, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Mar 20 21:56:46 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 1WQk18-0005uK-3h for ged-emacs-devel@m.gmane.org; Thu, 20 Mar 2014 21:56:46 +0100 Original-Received: from localhost ([::1]:49297 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WQk17-00059N-Lj for ged-emacs-devel@m.gmane.org; Thu, 20 Mar 2014 16:56:45 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53774) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WQk0x-00059B-3M for emacs-devel@gnu.org; Thu, 20 Mar 2014 16:56:43 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WQk0p-0001cd-1B for emacs-devel@gnu.org; Thu, 20 Mar 2014 16:56:35 -0400 Original-Received: from mercure.iro.umontreal.ca ([132.204.24.67]:38119) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WQk0g-0001bf-Ht; Thu, 20 Mar 2014 16:56:18 -0400 Original-Received: from hidalgo.iro.umontreal.ca (hidalgo.iro.umontreal.ca [132.204.27.50]) by mercure.iro.umontreal.ca (Postfix) with ESMTP id E67CD84D8C; Thu, 20 Mar 2014 16:56:17 -0400 (EDT) Original-Received: from lechon.iro.umontreal.ca (lechon.iro.umontreal.ca [132.204.27.242]) by hidalgo.iro.umontreal.ca (Postfix) with ESMTP id 884B61E5874; Thu, 20 Mar 2014 16:55:52 -0400 (EDT) Original-Received: by lechon.iro.umontreal.ca (Postfix, from userid 20848) id 40598B404C; Thu, 20 Mar 2014 16:55:52 -0400 (EDT) In-Reply-To: <83siqc7n87.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 20 Mar 2014 20:12:56 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-DIRO-MailScanner-Information: Please contact the ISP for more information X-DIRO-MailScanner: Found to be clean X-DIRO-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (score=-2.82, requis 5, autolearn=not spam, ALL_TRUSTED -2.82, MC_TSTLAST 0.00) X-DIRO-MailScanner-From: monnier@iro.umontreal.ca X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 132.204.24.67 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:170674 Archived-At: >> So "garbaged" means that we should not try to only redraw the parts that >> have changed. > When redisplay finds that a frame is "garbaged", it marks all of its > glyph matrix rows "disabled". This will force their complete > redrawing, as described above. Right, but that's not how "garbaged" is described (e.g. in the comment before it: "True if this frame should be redrawn"), hence the fuzzyness. The way I see it described, "garbaged" means that the display is not in sync with the matrices any more, but not that the matrices need to be recomputed. But the implementation you describe here implies that "garbaged" will end up recomputing all the matrices. And in turn I suspect some of the code takes advantage of the knowledge of how "garbaged" is implemented: it sets "garbaged" to cause the matrices to be recomputed (and the frame redrawn redrawn). > I don't think I understand what you meant to say here. But if you > were talking about what to do about a frame that was deiconified, I > think you need to call expose_frame, and arrange for the exposed > rectangle to cover the entire frame. That should do what you want, no > more, no less. Doesn't the windowing-system do that already for us? Stefan