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)
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.
Cheers,
JP.
--~--~---------~--~----~------------~-------~--~----~
Yi development mailing list
yi-devel@googlegroups.com
http://groups.google.com/group/yi-devel
-~----------~----~----~----~------~----~------~--~---
