> One of the  best ways to test speed impact on huge lists is to explore bits in a Form.

> It takes a while to process a million elements :-D
> [bits explore]timeToRun 89621

You're talking about trees, but this contributions was about lists. :-)

So far, we do not have managed to merge both into a unified framework ... Trees have true morphic nodes whereas lists optimize construction/memory, layouting, and rendering through a flat LazyListMorph. The advantage of the former are expressive, customizable object representations (e.g., for individual extents and formatting, submorphs, or interactive widgets to nodes) and support for exploration (scripting, halos) whereas the latter is significantly faster. I'm not sure which way we want to go in the long term. Can we make Morphic construction, layouting, and rendering lazy and fast enough to get rid of the LazyListMorph "hack" or do we have to build a LazyTreeMorph for fast huge trees (and add reification support/virtual halos for individual list/tree items (Marcel expressed this idea earlier))? It remains exciting ...

Best,
Christoph

________________________________
Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von karl ramberg <karlramberg at gmail.com>
Gesendet: Sonntag, 29. Januar 2023 11:56 Uhr
An: squeak-dev at lists.squeakfoundation.org
Betreff: Re: [squeak-dev] The Inbox: Morphic-ct.2082.mcz



On Sat, Jan 28, 2023 at 8:58 PM <commits at source.squeak.org<mailto:commits at source.squeak.org>> wrote:
Christoph Thiede uploaded a new version of Morphic to project The Inbox:
http://source.squeak.org/inbox/Morphic-ct.2082.mcz

==================== Summary ====================

Name: Morphic-ct.2082
Author: ct
Time: 28 January 2023, 8:57:55.639628 pm
UUID: dfcaa928-8758-5a42-a55b-2d89712a2a86
Ancestors: Morphic-mt.2081

To review: Fixes flickering in multi-column lists by ensuring sufficiently stable computation in #maxWidth.

This is likely to have a small but noticable negative impact on the performance for large lists, but I think this is inevitable if we want to avoid flickering. Otherwise, we could only consider computing the layout completely lazily during drawing.

One of the  best ways to test speed impact on huge lists is to explore bits in a Form.
It takes a while to process a million elements :-D
[bits explore]timeToRun 89621
Best,
Karl

[image.png]



For instance, the original bug can be reproduced by loading the SimulationMethodFinder from SimulationStudio, doing Morph new exploreProtocol and scrolling down until methodCommentAsBalloonHelp comes into view.

=============== Diff against Morphic-mt.2081 ===============

Item was changed:
  ----- Method: LazyListMorph>>maxWidth (in category 'layout') -----
  maxWidth
+       "Approximate the maximum width of this lazy list. Take all visible items as a sample.
+
+       NOTE that we MUST compute the width for all items in view!! Otherwise, maxWidth might be instable and be increased again during drawing in #item:, causing the receiver to flicker after each #layoutChanged (e.g., from PluggableMultiColumnListMorph>>#updateColumns)."
-       "Approximate the maximum width of this lazy list. Take first n items as a sample."

+       | listSize visibleBounds topRow bottomRow |
+       maxWidth ifNotNil: [^maxWidth].
+
-       | threshold listSize |
-       maxWidth ifNotNil:[^maxWidth].
-
-       threshold := 30.
        listSize := self getListSize.

+       visibleBounds := self bounds: self owner bounds from: self owner.
+       topRow := self rowAtLocation: visibleBounds topLeft.
+       bottomRow := self rowAtLocation: visibleBounds bottomLeft.
+
        maxWidth := 0.
+       topRow to: bottomRow do: [:index |
-       1 to: (threshold min: listSize) do: [:index |
                maxWidth := maxWidth max: (self widthToDisplayItem: (self getListItem: index))].
+
+       ^ maxWidth!
-
-       ^ maxWidth
- !


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20230129/c2ae6eb7/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 26950 bytes
Desc: image.png
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20230129/c2ae6eb7/attachment.png>