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 10:00:40 +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> 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 1279328460 2293 80.91.229.12 (17 Jul 2010 01:01:00 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 17 Jul 2010 01:01:00 +0000 (UTC) Cc: ofv@wanadoo.es, cyd@stupidchicken.com, 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 03:00:59 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 1OZvlx-0005mA-5r for ged-emacs-devel@m.gmane.org; Sat, 17 Jul 2010 03:00:57 +0200 Original-Received: from localhost ([127.0.0.1]:49499 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OZvlw-0000Hh-JA for ged-emacs-devel@m.gmane.org; Fri, 16 Jul 2010 21:00:56 -0400 Original-Received: from [140.186.70.92] (port=51857 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OZvlp-0000GY-0k for emacs-devel@gnu.org; Fri, 16 Jul 2010 21:00:50 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OZvln-0003dg-Ga for emacs-devel@gnu.org; Fri, 16 Jul 2010 21:00:48 -0400 Original-Received: from mathmail.math.s.chiba-u.ac.jp ([133.82.132.2]:54633) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OZvlj-0003dE-VU; Fri, 16 Jul 2010 21:00:44 -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 EE630C0560; Sat, 17 Jul 2010 10:00:40 +0900 (JST) In-Reply-To: <83fwzjg17j.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:127467 Archived-At: >>>>> On Fri, 16 Jul 2010 13:39:28 +0300, Eli Zaretskii said: >> The current code assumes that drawing is mainly done for updated >> area during redisplay, and expose_window is rather subsidiary. So >> the latter is not so optimized for frequent use. > Is it really worth our while to optimize that? What would be the > situation where we will get frequent expose events? If we change drawing during redisplay to addition of dirty area, then expose occurs on every window-system-level event handling or explicit flush. >> For example, it does not accept multiple rectangles for exposed >> area that is necessary for minimal redrawing. > Don't we get a single expose event for each exposed rectangular > area? If we do, what would be the gain from processing multiple > rectangles at once? I'm not X11 expert, but Expose event contains the `count' member. The count member is set to the number of Expose events that are to follow. If count is zero, no more Expose events follow for this window. However, if count is nonzero, at least that number of Expose events (and possibly more) follow for this window. Simple applications that do not want to optimize redisplay by distinguishing between subareas of its window can just ignore all Expose events with nonzero counts and perform full redisplays on events with zero counts. Cocoa has a special method for that. We can minimize rows to be drawn compared with a large union rectangle that overapproximately covers all rectangles, and we can reduce the overhead of processing the same window for possibly duplicated areas compared with calling expose_window for each rectangle. >> It also reuses functions primarily designed for drawing during >> redisplay and that does not necessarily efficient for exposure >> handing. > Are you talking about draw_glyphs? If so, how is it biased in favor > of redisplay, and what would be a more efficient way of drawing > glyphs in a specified area of the display than what draw_glyphs > does? 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. YAMAMOTO Mitsuharu mituharu@math.s.chiba-u.ac.jp