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 11:14:27 +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> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Trace: dough.gmane.org 1279246492 6380 80.91.229.12 (16 Jul 2010 02:14:52 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 16 Jul 2010 02:14:52 +0000 (UTC) Cc: =?ISO-8859-1?Q?=D3scar?= Fuentes , emacs-devel@gnu.org To: Chong Yidong Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jul 16 04:14:47 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 1OZaRm-0005Vv-EF for ged-emacs-devel@m.gmane.org; Fri, 16 Jul 2010 04:14:42 +0200 Original-Received: from localhost ([127.0.0.1]:58488 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OZaRl-0006hq-Qg for ged-emacs-devel@m.gmane.org; Thu, 15 Jul 2010 22:14:41 -0400 Original-Received: from [140.186.70.92] (port=49666 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OZaRf-0006hl-9v for emacs-devel@gnu.org; Thu, 15 Jul 2010 22:14:36 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OZaRd-000179-TH for emacs-devel@gnu.org; Thu, 15 Jul 2010 22:14:35 -0400 Original-Received: from mathmail.math.s.chiba-u.ac.jp ([133.82.132.2]:55539) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OZaRd-00014R-C9 for emacs-devel@gnu.org; Thu, 15 Jul 2010 22:14:33 -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 B38BCC0557; Fri, 16 Jul 2010 11:14:27 +0900 (JST) In-Reply-To: <877hkwag6y.fsf@stupidchicken.com> 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:127403 Archived-At: >>>>> On Thu, 15 Jul 2010 12:00:05 -0400, Chong Yidong said: > A more promising route is the one that Yamamoto Mitsuharu has > explored, mentioned earlier in this thread, which (IIUC) treats > Cairo as a graphical terminal to render onto, on the same footing as > the tty/X/Windows/NS terminals. Here, I can see a reasonable path > to real improvement. For example, it might allow us to use the GTK > printing infrastructure, which operates on Cairo contexts. If you > are interested in redisplay development, that is the direction I'd > suggest looking into. My proof-of-concept cairo port was primarily intended for the printing support, not for screen drawing (though it does both). http://lists.gnu.org/archive/html/emacs-devel/2009-04/msg00390.html Screen drawing in the cairo port is not so efficient for several reasons. To make it more efficient, one would need some modest modifications to the current drawing model in Emacs. 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. 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. 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. 4. Scrolling in redisplay (x_shift_glyphs_for_insert and x_scroll_run) might require special treatment because copied area might be marked dirty at the time of scrolling. YAMAMOTO Mitsuharu mituharu@math.s.chiba-u.ac.jp