Three demos showing how to improve drawing speed

The following demos took about 30 minutes to write, and much longer to write up here. Imo, they show the following: 1. There is a performance bug in p.moveToVisNext(). 2. There are several ways to work around the bug, speeding up the drawing code by about 25x. 3. The new data model would speed

Re: A detailed critique of the new data model

On Thursday, July 12, 2018 at 3:23:44 PM UTC-5, john lunzer wrote: > it's important at this point that we keep separate responsivity concerns and the merits of this or that data model. Exactly right. Doing so dooms the new model. In another thread I'll discuss a dead simple demo that shows

Re: A detailed critique of the new data model

I have been following this story with interest because it is my opinion that the responsivity of Leo's tree is not fast enough in enough cases to make it a daily annoyance. My fuzzy memory of participation in this group tells me that others feel similarly, though I will let them speak for

Re: A detailed critique of the new data model

On Thu, Jul 12, 2018 at 11:00 AM, vitalije wrote: > >> I have no further interest in the new data model. It won't happen while >> I am Leo's project leader. >> >> It will be good for Leo and it certainly will amuse me. When you finish >>> this project, I will run again the test used in the

Re: A detailed critique of the new data model

> > > I have no further interest in the new data model. It won't happen while I > am Leo's project leader. > > It will be good for Leo and it certainly will amuse me. When you finish >> this project, I will run again the test used in the video >>

Re: A detailed critique of the new data model

On Thursday, July 12, 2018 at 10:04:38 AM UTC-5, vitalije wrote: Ok. I will wait until you redesign the drawing code so that it gives us > possibility to make a fair comparison of speed between the new data model > and present Leo data model. > I have no further interest in the new data

Re: A detailed critique of the new data model

On Thu, Jul 12, 2018 at 9:20 AM, vitalije wrote: I hope you will reconsider this again. > ​I shall not. ​Quibbles aside, the proposal is 3 steps backward and no steps forward. There are no good reasons to mess with Leo's data model, and many good reasons not to. Edward -- You received this

Re: A detailed critique of the new data model

> > > As I have indicated elsewhere, Leo's *existing* Qt drawing code, > qtree.full_redraw, could be made *much* faster by drawing only N nodes. > Imo, this is the last remaining worthwhile project concerning the new data > model. > > Maintaining a generation count and outline list would speed

Re: A detailed critique of the new data model

> > There are three objections to the new model: > > 1. The new model abandons Leo's underlying DAG. > > The new model duplicates cloned nodes. Cloning a node can be arbitrarily > expensive in terms of space. > > This is just your guess not supported by any real measurement. All duplicated

Re: A detailed critique of the new data model

On Thursday, July 12, 2018 at 4:50:48 AM UTC-5, Edward K. Ream wrote: > ...the model does have one real speed advantage, the speed of next/prev_visible_index. The corresponding position methods are a bit slow in Leo. This is hardly surprising. In the new model these operations correspond to

A detailed critique of the new data model

At long last I understand the new data model in detail, having carefully re-read this post and its successors. I have three serious objections to the new data model: 1. It abandons Leo's underlying DAG. 2. It will not, in fact, be faster than