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: Sat, 17 Jul 2010 17:25:17 +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> <834ofyfsa8.fsf@gnu.org> 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 1279355137 30111 80.91.229.12 (17 Jul 2010 08:25:37 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 17 Jul 2010 08:25:37 +0000 (UTC) Cc: jan.h.d@swipnet.se, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jul 17 10:25:34 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 1Oa2iD-0006Ak-Ky for ged-emacs-devel@m.gmane.org; Sat, 17 Jul 2010 10:25:34 +0200 Original-Received: from localhost ([127.0.0.1]:52149 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Oa2iD-0005vp-0w for ged-emacs-devel@m.gmane.org; Sat, 17 Jul 2010 04:25:33 -0400 Original-Received: from [140.186.70.92] (port=55747 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Oa2i7-0005va-6K for emacs-devel@gnu.org; Sat, 17 Jul 2010 04:25:27 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Oa2i6-0000d1-7i for emacs-devel@gnu.org; Sat, 17 Jul 2010 04:25:27 -0400 Original-Received: from mathmail.math.s.chiba-u.ac.jp ([133.82.132.2]:54382) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Oa2i3-0000ce-Vi; Sat, 17 Jul 2010 04:25:24 -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 3100CC0560; Sat, 17 Jul 2010 17:25:18 +0900 (JST) In-Reply-To: <834ofyfsa8.fsf@gnu.org> 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:127496 Archived-At: >>>>> On Sat, 17 Jul 2010 11:04:31 +0300, Eli Zaretskii said: >> As I mentioned, row overlapping is handled in rather an inefficient >> way (by calling draw_glyphs for three times if the row is >> overlapping and overlapped). With double-buffering, we can draw >> whole the background of the specified area (possibly containing >> multiple rows) at once and then draw the whole foreground >> afterwards. > Someone should profile the current redisplay and see which part(s) > of it take most of the processing time. Without such a profile, we > are making the classic mistake of optimizing in a wrong place. I'm not saying that the current code (using Xlib for drawing) is slow. Even if expose_window is not so optimized, it doesn't matter that much because it is currently not so frequently called. If we stick to Xlib, there would be no need to modify the current drawing model. But if we switch to cairo, straightforward translation of Xlib drawing calls to cairo counterparts does not give a satisfactory result. I've just remembered another problem. If we use the current expose_window code for the printing support, it produces inefficient PDF. Notably, multiple drawings of the same text for handling overlapping rows causes duplicated text in PDF. That is, if you copy a text from a PDF viewer, you'll see a repetition of the same text. YAMAMOTO Mitsuharu mituharu@math.s.chiba-u.ac.jp