<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body>
<style type="text/css" style="display:none;"><!-- P {margin-top:0;margin-bottom:0;} --></style>
<div id="divtagdefaultwrapper" style="font-size:12pt;color:#000000;font-family:Calibri,Helvetica,sans-serif;" dir="ltr">
<p>Hi Marcel,</p>
<p><br>
</p>
<p>thank you for the feedback! Just to make sure we are talking about the same "little flickering", I'm attaching an example from the Protocol Explorer.</p>
<p><br>
</p>
<p>I did not run any benchmarks but just speculated about the performance impact. Do we have any ready-to-use benchmarks for that? The current logic is very imprecise anyway, as you can also see when you scroll through a list and suddenly a column is growing.
 Thus, how would you think about modifying this patch with ...</p>
<p><br>
</p>
<p><span>topRow to: (bottomRow <span style="color: rgb(255, 0, 0);">clampHigh: topRow + threshold</span>)</span><br>
</p>
<p><span><br>
</span></p>
<p><span>... so we could at least fix this issue for any lists that show not more than 30 items in the viewport, which should apply to a remarkable portion of all lists in a typical Squeak Trunk image. Then it should not worsen performance unless you are concerned
 about the constant geometry/getListSize costs added by the patch.</span></p>
<p><span><br>
</span></p>
<p><span>Best,</span></p>
<p><span>Christoph</span></p>
</div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>Von:</b> Squeak-dev <squeak-dev-bounces@lists.squeakfoundation.org> im Auftrag von Taeumel, Marcel via Squeak-dev <squeak-dev@lists.squeakfoundation.org><br>
<b>Gesendet:</b> Montag, 30. Januar 2023 11:06:24<br>
<b>An:</b> gettimothy via Squeak-dev<br>
<b>Betreff:</b> Re: [squeak-dev] The Inbox: Morphic-ct.2082.mcz</font>
<div> </div>
</div>
<div>
<div id="__MailbirdStyleContent" style="font-size: 10pt;font-family: Arial;color: #000000;text-align: left" dir="ltr">
Hi Christoph, hi all --
<div><br>
</div>
<div>Hmm... I would rather not sacrifice performance for a little bit less flickering. I would not want to have sluggish systems that appear calm but actually slow you down.</div>
<div><br>
</div>
<div>I think that it is not expedient to modify (and break) snappy things like LazyListMorph but rather write a new list widget that might replace the current one. Then, we can avoid having an intermediate state without a way to go back or forth, depending
 on the situation.</div>
<div><br>
</div>
<div>Best,</div>
<div>Marcel</div>
<div class="mb_sig"></div>
<blockquote class="history_container" type="cite" style="border-left-style:solid;border-width:1px; margin-top:20px; margin-left:0px;padding-left:10px;">
<p style="color: #AAAAAA; margin-top: 10px;">Am 28.01.2023 20:58:16 schrieb commits@source.squeak.org <commits@source.squeak.org>:</p>
<div style="font-family:Arial,Helvetica,sans-serif">Christoph Thiede uploaded a new version of Morphic to project The Inbox:<br>
http://source.squeak.org/inbox/Morphic-ct.2082.mcz<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>
<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>
</div>
</blockquote>
</div>
</div>
</body>
</html>