2009/7/30 Jean-Philippe Bernardy <jeanphilippe.berna...@gmail.com>: > > On Thu, Jul 30, 2009 at 10:20 AM, Krasimir Angelov<kr.ange...@gmail.com> > wrote: > >> I am surprised that you redraw the whole screen after each change. >> This is not the conventional solution and this is the problem. The >> solutions should be something like this: >> >> - the UI independent code should calculate which area of the buffer >> has been changed i.e. some rectangular area. >> - the GUI dependent code should call gtk_invalidate (I am not sure >> about the function name, the documentation should be checked) with the >> area that has been changed as an argument >> - the GTK main loop will call the redrawing method of the window at >> the right moment. The redrawing method will have to redraw only the >> range that has been changed. > > Pango is really in charge of this, so the best we can hope for is to > facilitate its job. > > When I wrote the code for this, I did something very simple: at each update, > the > layout object is passed the new version of the text and drawing > attributes (colors). > It may be that passing updates instead of a full new state will > accelerate the drawing. > (This can simply be done by running a minimum edit distance function > with the previous state)
One small optimization would be to use a separate pango layout object for each line and only update the lines that change. > > However, before trying that, I'd recommend checking > 1. That Pango can indeed optimize updates if it receives updates; and > 2. That the gtk2hs wrapper exposes the "update" interface, and doesn't > introduce some sort of bottleneck. (Like forcing a full > re-computation anyway) > > An alternative would be to take charge of layout ourselves, but that > might be difficult (non-monospace fonts, etc.) > and even slower. It might be wishful thinking, but a layout algorithm would let us use fancier graphics, and the same layout between Vty and Pango. Qemacs does this very nicely: http://fabrice.bellard.free.fr/qemacs/screenshots.html --~--~---------~--~----~------------~-------~--~----~ Yi development mailing list yi-devel@googlegroups.com http://groups.google.com/group/yi-devel -~----------~----~----~----~------~----~------~--~---
