This is exactly why I was reluctant to share unfinished prototype. I did beg you though, not to make any decisions before the prototype is finished, but it seems too hard to resist. I couldn't resist the temptation to share the unfinished code, you couldn't resits to make decisions.
I'll write more when I finish my prototype which can't happen in the next ten days. I have to focus on some other things in the following days. Vitalije On Friday, June 1, 2018 at 6:22:35 PM UTC+2, Edward K. Ream wrote: > > Here are my thoughts after several days of intense study of Vitalije's > prototype. > > 1. The top priority will be to accelerate Leo's read code, using > xml.etree.ElementTree and much faster scanning of external files. The goal > will be to be able to do without caching. Imo, it's doable. I'll create a > fast-read branch for this. > > 2. The second, lower, priority will be to heavily revise Leo's > tree-drawing code, following several ideas in the prototype. I'll create a > fast-draw branch for this. To summarize the essentials of Vitalije's > tree-drawing code: > > - No Tk items are ever recycled, they are reused instead. > - The Tk draw code draws only number of lines that are actually visible. > > It should be possible to apply exactly the same principles to the Qt > redraw code. In particular, Leo should only do *partial redraws*, that > is, redraws from a given top node to calculated bottom node. Not sure why > I didn't do that originally. And some new ideas have appeared: > > - The tree code might not ever have to save positions. Instead, an > item_to_position method might *reconstruct *a position from visible tree, > using just the position of the first visible line of the outline. > > - Leo should have a draw_from_position method, that will only ever do > partial redraws. To make this work, scrolling must trigger redraws. That > should be straightforward: we'll scroll only by whole lines. > > 3. Imo, all this can be done without changing Leo's existing vnode and > position classes. I have spent all morning studying the prototypes redraw > code. It's tricky to separate the effects of drawing from tree-traversal > issues, but my conclusion is that Leo's existing tree-traversal code is > roughly as fast as Vitalije's proposed revisions. > > *Summary* > > Imo, the present position and vnode classes are good enough. > > The real wins will be in the fast-read and fast-draw branches. > > Edward > -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
