Re: redisplay system of emacs

[alin.s]

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: 
http://old.nabble.com/redisplay-system-of-emacs-tp27349166p27564505.html
Sent from the Emacs - Dev mailing list archive at Nabble.com.