From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: YAMAMOTO Mitsuharu Newsgroups: gmane.emacs.devel Subject: Re: Emacs and Gnome Canvas Date: Sun, 18 Jul 2010 12:51:49 +0900 Organization: Faculty of Science, Chiba University Message-ID: References: <4C3CD120.4040905@swipnet.se> <5A91499A-0470-43FD-9F48-560CEAD3424C@mit.edu> <83wrsyr068.fsf@gnu.org> <83iq4hhjww.fsf@gnu.org> <87sk3lbvv0.fsf@telefonica.net> <83hbk1grnq.fsf@gnu.org> <4C3EBCDC.8050709@swipnet.se> <83d3upgmwj.fsf@gnu.org> <4C3ECB4C.6050208@swipnet.se> <83aaptgly1.fsf@gnu.org> <4C3ED4F9.4080603@swipnet.se> <83630hgi0r.fsf@gnu.org> <4C3EE8D6.3020607@swipnet.se> <8339vlgcax.fsf@gnu.org> <87fwzkbzg8.fsf@telefonica.net> <877hkwag6y.fsf@stupidchicken.com> <4C400B3C.4000203@swipnet.se> <83iq4fg3eb.fsf@gnu.org> <83fwzjg17j.fsf@gnu.org> <4C405398.4010203@swipnet.se> <4C416AC4.6030502@swipnet.se> <4C417580.5090905@swipnet.se> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1279425131 21736 80.91.229.12 (18 Jul 2010 03:52:11 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 18 Jul 2010 03:52:11 +0000 (UTC) Cc: ofv@wanadoo.es, Eli Zaretskii , cyd@stupidchicken.com, emacs-devel@gnu.org To: Jan =?ISO-8859-1?Q?Dj=E4rv?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jul 18 05:52:08 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1OaKv9-0005zz-Mb for ged-emacs-devel@m.gmane.org; Sun, 18 Jul 2010 05:52:08 +0200 Original-Received: from localhost ([127.0.0.1]:57424 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OaKv8-0004vE-Lm for ged-emacs-devel@m.gmane.org; Sat, 17 Jul 2010 23:52:06 -0400 Original-Received: from [140.186.70.92] (port=50989 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OaKv3-0004v9-5Q for emacs-devel@gnu.org; Sat, 17 Jul 2010 23:52:02 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OaKv2-0005A1-5T for emacs-devel@gnu.org; Sat, 17 Jul 2010 23:52:01 -0400 Original-Received: from mathmail.math.s.chiba-u.ac.jp ([133.82.132.2]:53938) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OaKuw-00059C-QZ; Sat, 17 Jul 2010 23:51:55 -0400 Original-Received: from church.math.s.chiba-u.ac.jp (church [133.82.132.36]) by mathmail.math.s.chiba-u.ac.jp (Postfix) with ESMTP id 2B2D9C0560; Sun, 18 Jul 2010 12:51:49 +0900 (JST) In-Reply-To: <4C41853E.6020601@swipnet.se> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/22.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) X-detected-operating-system: by eggs.gnu.org: NetBSD 3.0 (DF) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:127542 Archived-At: >>>>> On Sat, 17 Jul 2010 12:26:06 +0200, Jan Dj=E4rv = said: >> Sorry, I don't understand. Does GTK+ or GDK do double-buffering >> for drawings outside the handler of (possibly synthetic) expose >> events? > No, not outside expose events. But if I insert a character in a > text edit widget, it invalidates itself. That generates a syntetic > expose event. When the event is processed, Gdk arranges for all > drawings to go to the backing store. When the event is fully > processed, the backing store is copied to the window. That's what I've been talking: during redisplay, we invalidate the area to be updated (i.e., make it dirty) rather than drawing directly. Instead, all the drawings are done inside the expose handler. This way, double-buffering can be introduced straightforwardly. For example, the area that should be copied to the window is already passed to the handler, and we don't have to keep window and backing store contents in sync (the backing store can be created at the beginning of global expose handler without copying the current window contents to the buffer, and also can be freed after copying it to the window). It does match better with transparency or overlapping widgets. You've rather been talking about an alternative double-buffering that is for drawing during redisplay (i.e., outside the expose handler), and said that is how GTK+ operates all the time. YAMAMOTO Mitsuharu mituharu@math.s.chiba-u.ac.jp