> Is this a new layout problem? :-)

Showing visual progress is of course an overhead compared to not showing anything. The usual update rate is about 25 milliseconds? Hmmm... 11 vs. 18 seconds sounds reasonable given that you update the progress bar in this example about 400 times. This 7 second overhead amounts then to 17.5 milliseconds per update. Not good, right. Resizing my code browser from 500 to 1000 pixels in width takes about 4 milliseconds to re-layout -- but 36 milliseconds to re-layout and re-draw. Hmm....

We can improve those 17.5 milliseconds or increase the progress-bar update rate from 25 milliseconds to 200 milliseconds. :-)

Best,
Marcel
Am 06.10.2020 13:37:00 schrieb Thiede, Christoph <christoph.thiede at student.hpi.uni-potsdam.de>:
[(1 to: 1000) do: [:i | 10 milliSeconds wait]] timeToRun. "--> 11758"
[(1 to: 1000) do: [:i | 10 milliSeconds wait] displayingProgress: [:x | x asString]] timeToRun. "--> 18528"

18528 / 11758. "--> 1.57"


In this example, in total, 3.9 seconds are spent in SystemProgressMorph(Morph) >> #updateDropShadowCache. I found out that in #setLayoutBoundsFromLayout:, the #dropShadow cache is cleared in every second iteration of the code from above! Why is bounds ~= outer? Is this a new layout problem? :-)

Best,
Christoph
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20201006/756ec65c/attachment.html>