On 2013-09-02, at 18:24, Stephan Eggermont <stephan@stack.nl> wrote:

Camillo wrote:

...

the main problem with the current progress bar morph design is that updates are forced whenever the underlying model (here job) changes. This is *very* costly for high-frequency updates, which is exactly the moment when you want to use the progress bar ;)

It should work the other way around, the progress bar morph polls the underlying model with a given frequency (~10/s) and then refreshes the UI if the model changed.

I'm not in favor of polling. Most models are not thread-safe.

in this case it is only the instance of Job which knows the status. Thread-safeness is not an issue since the progress bar is pure approximation.

The progress bar knows how much precision it has (1% or so) and so knows at which boundaries it needs to refresh. In addition the progress bar should show that something is happening a few times a second.

that does not work properly and inaccurately reports long running jobs, for instance when running tests. Usually tests take far less than 1 ms, in which case this scheme works perfectly. However from time to time you have 1 test that runs for a couple of seconds. If you run 5000 tests you have to run quite a few tests to get that 1% update margin, so very often the UI does not correctly report the current status. Anyway, this requires quite some changes in the current ProgressBarMorph, so any other improvement until then is welcome :)

For the first, it would be enough to only call self changed in ProgressBarMorph>value: when the result would be visible, i.e. when the completedWidth changes.

ProgressBarMorph>value: aNumber |testWidth| value := aNumber. testWidth := self completedWidth. testWidth ~= cachedWidth ifTrue: [ cachedWidth := testWidth. self changed]

and setting the cachedWidth to 0 on initialize.

Hmm, where should I commit the 3.0 slice? Getting an error.

do you have an account on the Pharo30Inbox repository?