From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "alin.s" Newsgroups: gmane.emacs.devel Subject: Re: redisplay system of emacs Date: Fri, 12 Feb 2010 08:53:31 -0800 (PST) Message-ID: <27566385.post@talk.nabble.com> References: <27349166.post@talk.nabble.com> <27560255.post@talk.nabble.com> <4B754E74.8060705@swipnet.se> <27563610.post@talk.nabble.com> <4B7564C7.1010309@swipnet.se> <27564728.post@talk.nabble.com> <4B756FB7.3050202@swipnet.se> <87k4ui4gik.fsf@lola.goethe.zz> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1265993628 4058 80.91.229.12 (12 Feb 2010 16:53:48 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 12 Feb 2010 16:53:48 +0000 (UTC) To: Emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Feb 12 17:53:41 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 1Nfylv-0007cS-Ju for ged-emacs-devel@m.gmane.org; Fri, 12 Feb 2010 17:53:39 +0100 Original-Received: from localhost ([127.0.0.1]:40973 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Nfylv-0006Ay-2V for ged-emacs-devel@m.gmane.org; Fri, 12 Feb 2010 11:53:39 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Nfylp-000671-Pt for emacs-devel@gnu.org; Fri, 12 Feb 2010 11:53:33 -0500 Original-Received: from [140.186.70.92] (port=55716 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Nfylp-00065n-6E for Emacs-devel@gnu.org; Fri, 12 Feb 2010 11:53:33 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Nfylo-0000Xz-AO for Emacs-devel@gnu.org; Fri, 12 Feb 2010 11:53:33 -0500 Original-Received: from kuber.nabble.com ([216.139.236.158]:39147) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Nfylo-0000Xu-6m for Emacs-devel@gnu.org; Fri, 12 Feb 2010 11:53:32 -0500 Original-Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1Nfyln-0005JO-CJ for Emacs-devel@gnu.org; Fri, 12 Feb 2010 08:53:31 -0800 In-Reply-To: <87k4ui4gik.fsf@lola.goethe.zz> X-Nabble-From: alinsoar@voila.fr X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) 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:121082 Archived-At: I did not want to state categorically that such or such solution is the goo= d one. For example, if every emacs-window would be composed of lots of subwindows on server side, that lots of sub-windows could be completely hidden. Never use them to write something in them. They just report exactly the part of the buffer that should be redisplayed. They only catch and report events. They are invisible. Redisplay_internal does lots and lots of computations to detect which part of the buffer should be redisplayed at a given moment. All these computations can be avoided using a system of subwindows (1 for every char)= . That was my idea: to replace redisplay_internal with something simple and efficient. Something simple and efficient is to keep in the emacs a vector of little windows, and to register in the server all these windows. The structure of windows is changed only when configure event is caught or when one changes the font, or split windows, etc. So very rarely. 95% of the operations of redisplay can be covered with the system of little windows registered in the server. No more need of redisplay_internal for X. David Kastrup wrote: >=20 > Jan Dj=C3=A4rv writes: >=20 >> What you are describing is basically double buffering. Since Gtk+ >> does this already, it makes sense for Emacs to go that way too, >=20 > I don't see this dependency. >=20 >> either by using more Gtk+ (we now turn double buffering off), >=20 > In particular if one can tell Gtk+ not to double buffer. >=20 >> or develop its own. >=20 > I don't think that the performance in partly obscured windows is really > that important. >=20 > Or maybe I don't understand what this is about. >=20 > --=20 > David Kastrup >=20 >=20 >=20 >=20 >=20 --=20 View this message in context: http://old.nabble.com/redisplay-system-of-ema= cs-tp27349166p27566385.html Sent from the Emacs - Dev mailing list archive at Nabble.com.