Hi all, hi Marcel,

I just stumbled into another similar incident. I have a complex model that does a lazy-cached computation when it is asked the first time for the icons in a list. When the computation is run, the model spawns a progress bar to communicate the operation to the user. In theory, this would work fine, but in practice, if the computation takes more than 1 second to run, the progress bar will redraw the world and thus an almost-infinite loop occurs. Actually, after ~10 iterations the computation succeeds for an unknown reason, but it definitively is very inefficient and looks somehow awkward:

["awkward-progressbar.png"]

Do we need a second recursive lock somewhere around LazyListMorph >> #icon:? Or would you instead suggest to move this responsibility into the model? Conceptually, however, that approach would feel wrong to me because it is the view which defines the special recursive behavior in this case.

Here is the relevant recursive stack slice:

	... stuff in model ...
	PluggableMultiColumnListMorph>>iconAt:column:
	LazyListMorph>>getListIcon:
	LazyListMorph>>icon:
	LazyListMorph>>iconExtent
	LazyListMorph>>widthToDisplayItem:
	LazyListMorph>>item:
	LazyListMorph>>drawOn:
	LazyListMorph(Morph)>>fullDrawOn:
	[] in [] in PluggableMultiColumnListMorph(Morph)>>drawSubmorphsOn:
	[] in PluggableMultiColumnListMorph(Morph)>>drawSubmorphsOn:
	PluggableMultiColumnListMorph(Morph)>>drawSubmorphsOn:
	PluggableMultiColumnListMorph(Morph)>>fullDrawOn:
	...
	PasteUpMorph>>displayWorld
	[] in SystemProgressMorph>>position:label:min:max:
	...
	... stuff in model ...
	PluggableMultiColumnListMorph>>iconAt:column:
	LazyListMorph>>getListIcon:
	LazyListMorph>>icon:
	...

Best,
Christoph
-------------- next part --------------
A non-text attachment was scrubbed...
Name: awkward-progressbar.png
Type: application/octet-stream
Size: 17211 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20210616/9e53754a/attachment.obj>