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: Fri, 16 Jul 2010 19:01:18 +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> 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 1279274546 21901 80.91.229.12 (16 Jul 2010 10:02:26 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 16 Jul 2010 10:02:26 +0000 (UTC) Cc: =?ISO-8859-1?Q?=D3scar?= Fuentes , Chong Yidong , 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 Fri Jul 16 12:02:24 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 1OZhkI-0007KH-QC for ged-emacs-devel@m.gmane.org; Fri, 16 Jul 2010 12:02:19 +0200 Original-Received: from localhost ([127.0.0.1]:46365 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OZhkH-00060c-W2 for ged-emacs-devel@m.gmane.org; Fri, 16 Jul 2010 06:02:18 -0400 Original-Received: from [140.186.70.92] (port=47427 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OZhk7-00060T-Fq for emacs-devel@gnu.org; Fri, 16 Jul 2010 06:02:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OZhjP-0006KX-Dh for emacs-devel@gnu.org; Fri, 16 Jul 2010 06:01:24 -0400 Original-Received: from mathmail.math.s.chiba-u.ac.jp ([133.82.132.2]:55018) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OZhjO-0006K4-Sp for emacs-devel@gnu.org; Fri, 16 Jul 2010 06:01:23 -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 D05A3C0557; Fri, 16 Jul 2010 19:01:18 +0900 (JST) In-Reply-To: <4C400B3C.4000203@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:127420 Archived-At: >>>>> On Fri, 16 Jul 2010 09:33:16 +0200, Jan Dj=E4rv = said: >> 1. Don't draw during redisplay, but mark the updated area dirty so >> the upcoming exposure event can trigger the actual redraw for the >> area to be updated. > If some characters change attribute for example foreground color, > you have to draw it, there will be no expose. Whenever you need drawing outside exposure events, it should be replaced with addition of the dirty area. >> 2. Restrict the actual drawings to those in response to exposure >> events. This is the standard way in GTK+ and Cocoa. That would >> make double-buffering straightforward in GTK+ builds. > This is good, but can the current redisplay engine really update > just a part of the display area? Maybe we can set clipping to the > expose area?=20 Cocoa automatically does that. I'm not sure about others. > But most redrawings are not because of expose events, but of buffer > changes, so I don't know if this would be such a big improvement. > If you have double buffering, then you can just copy over the buffer > when expose happens. I've tried some double buffering in the cairo port (not in the posted patch) by allocating completely transparent image surface with alpha channel when we switch from Xlib drawing to cairo, and coping it when we have to switch back. The performance was not so satisfactory, maybe because of alpha blending overhead. Some documents might be useful to see why this model is recommended in many toolkits. Cocoa Fundamental Guide - The Core Application Architecture on Mac OS X - H= ow Views Get Drawn http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/Cocoa= Fundamentals/CoreAppArchitecture/CoreAppArchitecture.html#//apple_ref/doc/u= id/TP40002974-CH8-SW18 The GTK+ Drawing Model http://library.gnome.org/devel/gtk/stable/chap-drawing-model.html Some inefficiency specific to the cairo port comes from repeated acquisition/release of Xlib surface during redisplay. This can be simplified if drawing is restricted to exposure. >> 3. Make expose_window etc. more efficient. For example, the >> foreground of same row might currently be redrawn three times for >> some cases in order to handle overlaps between rows with minimal >> flickering. This can be eliminated if double-buffering is >> introduced and whole the background is drawn at once and then whole >> the foreground is drawn afterwards. > Are there many of these "reduce flicker" drawings going on? It depends on the fonts used. > Double buffer would be nice, I think it could help with images also > (now images are drawn to a pixmap first, then copied to the frame). Yes. Many of such code can simplified. YAMAMOTO Mitsuharu mituharu@math.s.chiba-u.ac.jp