[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 05:30:51 -0800 (PST)

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
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
  How do you purpose we lay this out?  Instead of laying out characters we
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
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

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: 
Sent from the Emacs - Dev mailing list archive at Nabble.com.

reply via email to

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