On Thu, Jul 30, 2009 at 10:13 AM, Colin McQuillan<m.ni...@googlemail.com> wrote:
> What operation will asynchronous rendering make faster? There are two operations that are costly: (supposedly) 1. Computing the information to show the user (ui-independent) 2. Putting that information on the screen (ui-dependent) The idea is to pipeline this process: stage 2 for iteration n can be run in parallel to stage 1 for iteration (n+1). > Pasting to the > Pango frontend is already fast because we insert all the characters at > once. Pasting to the vty frontend could be improved by only redrawing > when there is no more tty input. There is no way to predict when input will stop. So the only option is to place a delay on the redraw. Maybe a delay of 0.01s could be acceptable? > Cursor movement really should be fast enough not to need threading. > For me, this is the most frustrating problem. All updates are treated > the same and cause a complete refresh. There could be a fast path for > updates that only change the display. I believe that all user input should be treated the same way. Why would a delay be acceptable on some type of input and not some other? I dislike optimizing by breaking into special cases and optimizing each because it increases the complexity and the amount of work. I'd rather find optimizations for the general case. > Other editors are written to > minimize the amount that needs to be redrawn. Perhaps FRP could help? There is code in vty that makes sure only changed parts of the display are sent to the terminal. > Threading will be necessary for doing syntax highlighting in the > background. I don't know how to do this in a way that doesn't involve lots of updates to a complex state. Since this has a strong imperative flavor, I've stayed away from this approach. Cheers, JP. --~--~---------~--~----~------------~-------~--~----~ Yi development mailing list yi-devel@googlegroups.com http://groups.google.com/group/yi-devel -~----------~----~----~----~------~----~------~--~---
