[squeak-dev] Overhead of SystemProgressMorph/#do:displayingProgress: is huge

Thiede, Christoph Christoph.Thiede at student.hpi.uni-potsdam.de
Tue Oct 6 13:09:31 UTC 2020


Hi Marcel,


while doing a #do:displayingProgress: operation, nothing should be redrawn but the inner progress bar rectangle (and maybe the system clock), unless other morphs are changed at the same time, is this correct? In this case I do not understand why the dropShadow has to be recomputed within every draw cycle. Of 7.5 seconds in PasteUpMorph >> #displayWorld, my TimeProfileBrowser shows 5.3 seconds in #updateDropShadowCache.  Sorry for the ugly screenshot:


[cid:25f1bcc4-8b9c-4c0c-9328-1c08d3491e65]


Apart from that, I think 10 fps would be enough, too, yes. Maybe we should reuse the selectionUpdateTime mechanism from Inspector if the displayDuring-aStringOrBlock block takes more time. :-)


Best,

Christoph

<http://www.hpi.de/>
________________________________
Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von Taeumel, Marcel
Gesendet: Dienstag, 6. Oktober 2020 14:32:17
An: squeak-dev
Betreff: Re: [squeak-dev] Overhead of SystemProgressMorph/#do:displayingProgress: is huge

> 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/632f7c27/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pastedImage.png
Type: image/png
Size: 373109 bytes
Desc: pastedImage.png
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20201006/632f7c27/attachment-0001.png>


More information about the Squeak-dev mailing list