Indeed. For example, in the context of Moose, we sometimes have lists in the order of 100k elements. The LazyMorphTreeMorph offers pagination and it works well, but it would be super cool to have a stronger solution.
Cheers, Doru On 6 Apr 2011, at 10:08, Stéphane Ducasse wrote: > Hi guys > > this is ***REALLLYYYYY*** important that we get scalable List and Tree > so thanks a lot for your effort. > Please continue > Stef > > On Apr 6, 2011, at 10:02 AM, Igor Stasenko wrote: > >> On 6 April 2011 09:45, Alain Plantec <alain.plan...@yahoo.com> wrote: >>> Le 06/04/2011 08:57, Igor Stasenko a écrit : >>>> >>>>> another point, try all examples in Morphic-MorphTreeWidget-Examples. >>>>> now, the height of each row is constant. >>>> >>>> Yes, so what it should be instead? >>> >>> it should be dependent on the content height, so as it was before. >>> another problem is the spacers removal. >>> now, the horizontal positioning is broken (they was here to take into >>> account the vertical resizers width) >>> see the screen shots. >>> >> >> yes, positioning is not quite correct. But the idea is to use layouts >> instead of morphs to >> adjust positioning. >> Because having 3 extra morphs per list item which sitting there only >> for markup is not fun. >> And it affects a rendering speed considerably. >> >>> try SimpleGridExample new open before and after the changes. >>> to exhibit the problem, change the resizerWidth from 2 to 12 as an example >>> (just set it to 12 in SimpleGridExample>>treeMorph) >>> >>> I think that MorphTreeMorph can't be efficient for very big lists >>> because each row may contain a lot of morphs. >> >> Yes, but you can use morphs only for those items which are shown on >> screen, while for those which outside >> you don't need to use morphs at all. >> >> The idea is that You could keep in memory all morphs which >> representing the tree, but don't iterate over them >> every time. Just add to submorphs only those which currently visible. >> >>> This is why I've also implemented LazyMorphTreeMorph. >>> Try it, it is very much efficient but badly implemented. >>> I think it should use a background process to build the list >>> (something like what you did for the annotation pane). >>> >> What could be done is to simplify things even more, so creating a list >> item will be cheaper and skip many initialization, >> unless it is necessary. >> >>> Cheers >>> Alain >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> > > -- www.tudorgirba.com "Relationships are of two kinds: those we choose and those that happen. They both matter."
