emacs-devel
[Top][All Lists]
Advanced

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

Re: redisplay system of emacs


From: Jan Djärv
Subject: Re: redisplay system of emacs
Date: Fri, 12 Feb 2010 15:25:11 +0100
User-agent: Thunderbird 2.0.0.23 (X11/20090817)

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.





reply via email to

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