From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?UTF-8?B?SmFuIERqw6Rydg==?= Newsgroups: gmane.emacs.devel Subject: Re: Emacs and Gnome Canvas Date: Thu, 15 Jul 2010 10:48:12 +0200 Message-ID: <4C3ECB4C.6050208@swipnet.se> 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> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1279183711 22726 80.91.229.12 (15 Jul 2010 08:48:31 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 15 Jul 2010 08:48:31 +0000 (UTC) Cc: ofv@wanadoo.es, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jul 15 10:48:29 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 1OZK7H-0006qo-O3 for ged-emacs-devel@m.gmane.org; Thu, 15 Jul 2010 10:48:28 +0200 Original-Received: from localhost ([127.0.0.1]:52537 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OZK7H-0003pE-5k for ged-emacs-devel@m.gmane.org; Thu, 15 Jul 2010 04:48:27 -0400 Original-Received: from [140.186.70.92] (port=46353 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OZK78-0003m5-Cv for emacs-devel@gnu.org; Thu, 15 Jul 2010 04:48:22 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OZK77-0003dN-2a for emacs-devel@gnu.org; Thu, 15 Jul 2010 04:48:18 -0400 Original-Received: from smtprelay-h31.telenor.se ([213.150.131.4]:47577) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OZK75-0003cf-3M; Thu, 15 Jul 2010 04:48:15 -0400 Original-Received: from ipb1.telenor.se (ipb1.telenor.se [195.54.127.164]) by smtprelay-h31.telenor.se (Postfix) with ESMTP id 61D00E961A; Thu, 15 Jul 2010 10:48:13 +0200 (CEST) X-SENDER-IP: [85.225.45.35] X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Asw1AO1nPkxV4S0jPGdsb2JhbACDH4RSmAAMAQEBATUtrHWRQIEpgwlyBA X-IronPort-AV: E=Sophos;i="4.55,206,1278280800"; d="scan'208";a="105673179" Original-Received: from c-232de155.25-1-64736c10.cust.bredbandsbolaget.se (HELO coolsville.localdomain) ([85.225.45.35]) by ipb1.telenor.se with ESMTP; 15 Jul 2010 10:48:12 +0200 Original-Received: from [172.20.199.13] (zeplin [172.20.199.13]) by coolsville.localdomain (Postfix) with ESMTPSA id A78897FA05A; Thu, 15 Jul 2010 10:48:12 +0200 (CEST) User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; sv-SE; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1 In-Reply-To: <83d3upgmwj.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. 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:127334 Archived-At: Eli Zaretskii skrev 2010-07-15 10.38: >> Date: Thu, 15 Jul 2010 09:46:36 +0200 >> From: Jan Dj=C3=A4rv >> CC: =C3=93scar Fuentes, >> emacs-devel@gnu.org >> >>> . Canvas redisplay is caused by requests from the application to >>> update some "canvas item" when the underlying application's obje= cts >>> are modified; these requests are then served when GTK+ idle >>> handlers are run. Emacs display engine works differently: chang= es >>> that require redisplay are not considered until redisplay is >>> entered; the "requests" to update the display are implicitly >>> recorded in the buffers and in the various related data structur= es >>> (text properties and overlays, display strings, etc.), but not >>> explicitly translated to display terms until redisplay time, and= as >>> an inherent part of redisplay itself. These two very different >>> models will need to be reconciled in some reasonably efficient w= ay. >> >> The changes that require redisplay would have to notify the Canvas tha= t things >> changed. I think this style is more efficient. > > What do you mean by "changes that require redisplay"? Suppose a > character was inserted or deleted -- would that need to notify the > Canvas? Yes. > How about an arbitrary mouse move? If it resulted in a different highlightning of a link, yes. Jan D. >