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 05:30:51 -0800 (PST) Message-ID: <27563610.post@talk.nabble.com> References: <27349166.post@talk.nabble.com> <27560255.post@talk.nabble.com> <4B754E74.8060705@swipnet.se> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1265981463 25447 80.91.229.12 (12 Feb 2010 13:31:03 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 12 Feb 2010 13:31:03 +0000 (UTC) To: Emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Feb 12 14:31:01 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 1Nfvbo-0000ph-Mx for ged-emacs-devel@m.gmane.org; Fri, 12 Feb 2010 14:31:01 +0100 Original-Received: from localhost ([127.0.0.1]:43503 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Nfvbo-0003gK-3e for ged-emacs-devel@m.gmane.org; Fri, 12 Feb 2010 08:31:00 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Nfvbi-0003eQ-5e for emacs-devel@gnu.org; Fri, 12 Feb 2010 08:30:54 -0500 Original-Received: from [140.186.70.92] (port=53281 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Nfvbh-0003db-Ea for Emacs-devel@gnu.org; Fri, 12 Feb 2010 08:30:53 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Nfvbg-0007KI-It for Emacs-devel@gnu.org; Fri, 12 Feb 2010 08:30:53 -0500 Original-Received: from kuber.nabble.com ([216.139.236.158]:59748) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Nfvbg-0007K8-Cu for Emacs-devel@gnu.org; Fri, 12 Feb 2010 08:30:52 -0500 Original-Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1Nfvbf-0003MU-Al for Emacs-devel@gnu.org; Fri, 12 Feb 2010 05:30:51 -0800 In-Reply-To: <4B754E74.8060705@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:121074 Archived-At: 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. You are mad. Everything would be 1400 times more. 1400 times more calls to the X server, 1400 times more GC:s created, 1400 times more events from the X server, 1400 times more Xft structures (XftDraws for example) created. Emacs would be at least 1400 times slower. The computations are not done as you say. Please read the X windows manual. If you make 1000 identical calls of Xlib functions, Xlib put them into its queue, and send them once. On the other side, taking into account that I forgot a ZERO, we could have many times calls to Xlib, but anyways, not too much, taking into account the queue of Xlib. 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. You do not need 14.000 Graphics Contextes, only 1 for window is enough! It is not 14000 times slower, it is a few times faster. It is many times more consuming of memory of the server side. Please learn Xlib programming to understand it. > > 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. So say we have 1400 windows each with a different font with a different size? How do you purpose we lay this out? Instead of laying out characters we are now laying out windows. Same problem, but with an enormous overhead. Same problem, only 1 GC for every window. > > 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. Again, making the display of an image to be so much slower, because instead of one (ideally), call to the X server, we now have one per window. And what a nightmare to figure out what part of an image that needs to be redrawn and moved if the user changes the size of the Emacs frame... We do have 1 call for window, and 1 network message to the server for every update. The only problem in this implementation would be to compute the size of every window, and to compute its coordinates. > > And finally, because this structure is identical to the geometry of the > console, the code for X and console can be unified in many places. > Not very likely. I do not know. Maybe. -- View this message in context: http://old.nabble.com/redisplay-system-of-emacs-tp27349166p27563610.html Sent from the Emacs - Dev mailing list archive at Nabble.com.