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: Emacs Mac port Date: Tue, 16 Apr 2013 09:20:15 -0400 Message-ID: References: <83ip3p72mz.fsf@gnu.org> <83d2tw73h7.fsf@gnu.org> <8361zo6um1.fsf@gnu.org> <8338us6oz9.fsf@gnu.org> <838v4j55si.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1366122529 24882 80.91.229.3 (16 Apr 2013 14:28:49 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 16 Apr 2013 14:28:49 +0000 (UTC) Cc: Eli Zaretskii , emacs-devel@gnu.org To: YAMAMOTO Mitsuharu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Apr 16 16:28:53 2013 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 1US6sN-0004Gy-EY for ged-emacs-devel@m.gmane.org; Tue, 16 Apr 2013 16:28:51 +0200 Original-Received: from localhost ([::1]:60950 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1US6sM-0005ED-Ir for ged-emacs-devel@m.gmane.org; Tue, 16 Apr 2013 10:28:50 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:33555) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1US6sI-0005Bw-T1 for emacs-devel@gnu.org; Tue, 16 Apr 2013 10:28:48 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1US6Hl-0003Qb-CZ for emacs-devel@gnu.org; Tue, 16 Apr 2013 09:51:02 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.182]:22455) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1US5o0-0001Fi-TQ; Tue, 16 Apr 2013 09:20:16 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EABK/CFHO+LAd/2dsb2JhbABEDr8AF3OCHgEBBAFWIwULCzQSFBgNJIgeBrEfkA6NDoN8A6R6gV6COVo X-IPAS-Result: Av4EABK/CFHO+LAd/2dsb2JhbABEDr8AF3OCHgEBBAFWIwULCzQSFBgNJIgeBrEfkA6NDoN8A6R6gV6COVo X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="7524164" Original-Received: from 206-248-176-29.dsl.teksavvy.com (HELO pastel.home) ([206.248.176.29]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 16 Apr 2013 09:20:12 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 761566787A; Tue, 16 Apr 2013 09:20:15 -0400 (EDT) In-Reply-To: (YAMAMOTO Mitsuharu's message of "Tue, 16 Apr 2013 19:15:45 +0900") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.182 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:158948 Archived-At: > That shows a typical reason why recent toolkits treat the "expose" > handler as the primary drawing method. By freshly redrawing > invalidated area in a rear-to-front way, it can provide some fancy > appearances such as overlapped/translucent widgets in a correct way. So IIUC, the "new normal" way you describe goes something like: - redisplay builds glyph matrices from Lisp data and invalidates the parts of the display that might need to be redrawn but does not draw. - expose handlers use the glyph matrices to draw on the screen when/where needed. That makes a lot of sense. Stefan