Re: redisplay system of emacs

[alin.s]

I did not want to state categorically that such or such solution is the good
one.

For example, if every emacs-window would be composed of lots of subwindows
on server side, that lots of sub-windows could be completely hidden. Never
use them to write something in them. They just report exactly the part of
the buffer that should be redisplayed. They only catch and report events.
They are invisible.

Redisplay_internal does lots and lots of computations to detect which part
of the buffer should be redisplayed at a given moment. All these
computations can be avoided using a system of subwindows (1 for every char).
That was my idea: to replace redisplay_internal with something simple and
efficient. Something simple and efficient is to keep in the emacs a vector
of little windows, and to register in the server all these windows.

The structure of windows is changed only when configure event is caught or
when one changes the font, or split windows, etc. So very rarely.

95% of the operations of redisplay can be covered with the system of little
windows registered in the server. No more need of redisplay_internal for X.





David Kastrup wrote:
> 
> Jan Djärv <address@hidden> writes:
> 
>> What you are describing is basically double buffering.  Since Gtk+
>> does this already, it makes sense for Emacs to go that way too,
> 
> I don't see this dependency.
> 
>> either by using more Gtk+ (we now turn double buffering off),
> 
> In particular if one can tell Gtk+ not to double buffer.
> 
>> or develop its own.
> 
> I don't think that the performance in partly obscured windows is really
> that important.
> 
> Or maybe I don't understand what this is about.
> 
> -- 
> David Kastrup
> 
> 
> 
> 
> 

-- 
View this message in context: 
http://old.nabble.com/redisplay-system-of-emacs-tp27349166p27566385.html
Sent from the Emacs - Dev mailing list archive at Nabble.com.