<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" style="display:none;"><!-- P {margin-top:0;margin-bottom:0;} --></style>
</head>
<body dir="ltr">
<div id="divtagdefaultwrapper" style="font-size: 12pt; color: rgb(0, 0, 0); font-family: Calibri, Helvetica, sans-serif, EmojiFont, "Apple Color Emoji", "Segoe UI Emoji", NotoColorEmoji, "Segoe UI Symbol", "Android Emoji", EmojiSymbols;" dir="ltr">
<p>> <span style="font-size: 12pt;">One of the best ways to test speed impact on huge lists is to explore bits in a Form.</span></p>
<div>> It takes a while to process a million elements :-D</div>
<div>> [bits explore]timeToRun 89621</div>
<div><br>
</div>
<div>You're talking about trees, but this contributions was about lists. :-)</div>
<div><br>
</div>
<div>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 ...</div>
<div><br>
</div>
<div>Best,</div>
<div>Christoph</div>
<p></p>
<br>
<div style="color: rgb(0, 0, 0);">
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>Von:</b> Squeak-dev <squeak-dev-bounces@lists.squeakfoundation.org> im Auftrag von karl ramberg <karlramberg@gmail.com><br>
<b>Gesendet:</b> Sonntag, 29. Januar 2023 11:56 Uhr<br>
<b>An:</b> squeak-dev@lists.squeakfoundation.org<br>
<b>Betreff:</b> Re: [squeak-dev] The Inbox: Morphic-ct.2082.mcz</font>
<div> </div>
</div>
<div>
<div dir="ltr">
<div dir="ltr"><br>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Sat, Jan 28, 2023 at 8:58 PM <<a href="mailto:commits@source.squeak.org">commits@source.squeak.org</a>> wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex; border-left:1px solid rgb(204,204,204); padding-left:1ex">
Christoph Thiede uploaded a new version of Morphic to project The Inbox:<br>
<a href="http://source.squeak.org/inbox/Morphic-ct.2082.mcz" rel="noreferrer" target="_blank">http://source.squeak.org/inbox/Morphic-ct.2082.mcz</a><br>
<br>
==================== Summary ====================<br>
<br>
Name: Morphic-ct.2082<br>
Author: ct<br>
Time: 28 January 2023, 8:57:55.639628 pm<br>
UUID: dfcaa928-8758-5a42-a55b-2d89712a2a86<br>
Ancestors: Morphic-mt.2081<br>
<br>
To review: Fixes flickering in multi-column lists by ensuring sufficiently stable computation in #maxWidth.<br>
<br>
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.<br>
</blockquote>
<div><br>
</div>
<div>One of the best ways to test speed impact on huge lists is to explore bits in a Form.</div>
<div>It takes a while to process a million elements :-D</div>
<div>[bits explore]timeToRun 89621 </div>
<div>Best,</div>
<div>Karl<br>
</div>
<div> <br>
</div>
<div><img naturalheight="346" naturalwidth="728" alt="image.png" width="488" height="232" style="user-select: none;" src="cid:ii_ldh9h7r20"><br>
<br>
</div>
<div> <br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex; border-left:1px solid rgb(204,204,204); padding-left:1ex">
<br>
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.<br>
<br>
=============== Diff against Morphic-mt.2081 ===============<br>
<br>
Item was changed:<br>
----- Method: LazyListMorph>>maxWidth (in category 'layout') -----<br>
maxWidth<br>
+ "Approximate the maximum width of this lazy list. Take all visible items as a sample.<br>
+ <br>
+ 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)."<br>
- "Approximate the maximum width of this lazy list. Take first n items as a sample."<br>
<br>
+ | listSize visibleBounds topRow bottomRow |<br>
+ maxWidth ifNotNil: [^maxWidth].<br>
+ <br>
- | threshold listSize |<br>
- maxWidth ifNotNil:[^maxWidth].<br>
- <br>
- threshold := 30.<br>
listSize := self getListSize.<br>
<br>
+ visibleBounds := self bounds: self owner bounds from: self owner.<br>
+ topRow := self rowAtLocation: visibleBounds topLeft.<br>
+ bottomRow := self rowAtLocation: visibleBounds bottomLeft.<br>
+ <br>
maxWidth := 0.<br>
+ topRow to: bottomRow do: [:index |<br>
- 1 to: (threshold min: listSize) do: [:index |<br>
maxWidth := maxWidth max: (self widthToDisplayItem: (self getListItem: index))].<br>
+ <br>
+ ^ maxWidth!<br>
- <br>
- ^ maxWidth<br>
- !<br>
<br>
<br>
</blockquote>
</div>
</div>
</div>
</div>
</div>
</body>
</html>