[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: redisplay system of emacs

From: alin.s
Subject: Re: redisplay system of emacs
Date: Fri, 12 Feb 2010 06:37:56 -0800 (PST)

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ärv wrote:
> alin.s skrev:
>> 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.
> I have done so for every edition since X10.
>> If you make 1000 identical calls of Xlib functions, Xlib put them into
>> its
>> queue, and send them once.
> Yes it does put calls in a queue.  All 1400 of them instead of one.  But
> given 
> how IPC works, in reality it will be many writes to the socket anyway,
> even if 
> the queue tries to minimize that.  And the amount of data is still 1400
> (or 
> 14000) times more.  X does not squeeze several calls into one, there are
> still 
> several calls.  And they are not identical anyway, they are for different
> windows.
>> 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.
> But you have to keep track of all handles to these data as well in Emacs
> so 
> both have to have 14000 times more data.
>> You do not need 14.000 Graphics Contextes, only 1 for window is enough!
> Ok, so GC:s wasn't a good example.
>> It is many times more consuming of memory of the server side. Please
>> learn
>> Xlib programming to understand it.
> No need to be condescending, it doesn't help your cause.  I've done X 
> programming since the late 80:s.
>>> 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.
> No it is not the same problem.  For every window you will have to tell X
> where 
> it will be positioned, i,e. x and y and width and height.  If every window 
> have its own font with its own size you have to calculate all this for
> every 
> window, and the recalculate it for all windows when a font changes in one 
> window.  Sounds like what redisplay does today.
>>> 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.
> ... times 14000 windows...
>> The only problem in this implementation would be to compute the size of
>> every window, and to compute its coordinates.
> So you have gained nothing really, redisplay is the hard part.
>       Jan D.

View this message in context: 
Sent from the Emacs - Dev mailing list archive at Nabble.com.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]