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 06:37:56 -0800 (PST) Message-ID: <27564505.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> 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 1265985692 7413 80.91.229.12 (12 Feb 2010 14:41:32 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 12 Feb 2010 14:41:32 +0000 (UTC) To: Emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Feb 12 15:41: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 1Nfwi0-0000nj-SY for ged-emacs-devel@m.gmane.org; Fri, 12 Feb 2010 15:41:29 +0100 Original-Received: from localhost ([127.0.0.1]:53108 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Nfwem-0003j5-La for ged-emacs-devel@m.gmane.org; Fri, 12 Feb 2010 09:38:08 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Nfwef-0003dV-5G for emacs-devel@gnu.org; Fri, 12 Feb 2010 09:38:01 -0500 Original-Received: from [140.186.70.92] (port=39562 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Nfwec-0003Y6-VK for Emacs-devel@gnu.org; Fri, 12 Feb 2010 09:38:00 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Nfweb-0004ld-QQ for Emacs-devel@gnu.org; Fri, 12 Feb 2010 09:37:58 -0500 Original-Received: from kuber.nabble.com ([216.139.236.158]:57007) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Nfweb-0004lZ-He for Emacs-devel@gnu.org; Fri, 12 Feb 2010 09:37:57 -0500 Original-Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1Nfwea-00010o-MA for Emacs-devel@gnu.org; Fri, 12 Feb 2010 06:37:56 -0800 In-Reply-To: <4B7564C7.1010309@swipnet.se> 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:121076 Archived-At: I agree that it is not a good plan . I thought that the X server notifies you exactly the characters that need redisplaying, and so it would be very clear the redisplay for everybody ! Jan Dj=C3=A4rv wrote: >=20 > alin.s skrev: >>=20 >>=20 >> alin.s skrev: >>> An improvement in redisplay for X can be done by defining in the edit >>> area >>> of >>> every window a subwindow for every character. For a window of geometry >>> 200x70 of characters, it would be 1400 windows registered in X-server. >>=20 >> You are mad. Everything would be 1400 times more. 1400 times more call= s >> to=20 >> the X server, 1400 times more GC:s created, 1400 times more events from >> the >> X=20 >> server, 1400 times more Xft structures (XftDraws for example) created. >> Emacs would be at least 1400 times slower. >>=20 >> The computations are not done as you say. Please read the X windows >> manual. >=20 > I have done so for every edition since X10. >=20 >>=20 >> If you make 1000 identical calls of Xlib functions, Xlib put them into >> its >> queue, and send them once. >>=20 >=20 > Yes it does put calls in a queue. All 1400 of them instead of one. But > given=20 > how IPC works, in reality it will be many writes to the socket anyway, > even if=20 > the queue tries to minimize that. And the amount of data is still 1400 > (or=20 > 14000) times more. X does not squeeze several calls into one, there are > still=20 > several calls. And they are not identical anyway, they are for different > windows. >=20 >>=20 >> I do not know what is bad to keep in the server 100.000 of little >> structures. Apart from memory consuming, no problem of speed. >=20 > But you have to keep track of all handles to these data as well in Emacs > so=20 > both have to have 14000 times more data. >=20 >>=20 >> You do not need 14.000 Graphics Contextes, only 1 for window is enough! >=20 > Ok, so GC:s wasn't a good example. >=20 >> It is many times more consuming of memory of the server side. Please >> learn >> Xlib programming to understand it. >=20 > No need to be condescending, it doesn't help your cause. I've done X=20 > programming since the late 80:s. >=20 >>=20 >>> To say more, in order to clear a character it would require no >>> computation, >>> but only a simply call of XClearWindow(). >>> >>> Every window could have its own font. >>=20 >> So say we have 1400 windows each with a different font with a different >> size?=20 >> How do you purpose we lay this out? Instead of laying out characters >> we >> are=20 >> now laying out windows. Same problem, but with an enormous overhead. >>=20 >> Same problem, only 1 GC for every window. >=20 > No it is not the same problem. For every window you will have to tell X > where=20 > it will be positioned, i,e. x and y and width and height. If every windo= w=20 > have its own font with its own size you have to calculate all this for > every=20 > window, and the recalculate it for all windows when a font changes in one= =20 > window. Sounds like what redisplay does today. >=20 >>=20 >>> And to say more, an image of high dimension will be divided in many >>> subwindows, and emacs will be able to display images normally, not as a >>> huge >>> glyph. >>=20 >> Again, making the display of an image to be so much slower, because >> instead >> of=20 >> one (ideally), call to the X server, we now have one per window. And >> what a=20 >> nightmare to figure out what part of an image that needs to be redrawn >> and=20 >> moved if the user changes the size of the Emacs frame... >>=20 >> We do have 1 call for window, and 1 network message to the server for >> every >> update. >=20 > ... times 14000 windows... >=20 >>=20 >> The only problem in this implementation would be to compute the size of >> every window, and to compute its coordinates. >=20 > So you have gained nothing really, redisplay is the hard part. >=20 > =09Jan D. >=20 >=20 >=20 >=20 >=20 --=20 View this message in context: http://old.nabble.com/redisplay-system-of-ema= cs-tp27349166p27564505.html Sent from the Emacs - Dev mailing list archive at Nabble.com.