Progress notification

Currently, we use an event based progress architecture, with
vestiges of the 
old publish/subscribe architecture. This architecture has a
couple of big 
problems (for the sake of discussion, an action is something
like a filter 
process() call or a visitor call):

* not thread-safe
* cannot handle more than one progressing action at the same
time
* uses processEvents (which is dangerous)
* costs us quite a bit of cpu

We need to replace it, therefore. The list of problems is
very nearly the list 
of requirements for the replacement:

* threadsafe (should be able to handle updates from
different threads within 
the same action and still show a continuous progress towards
100%)
* be able to handle more than one concurrent action
* be safe
* be cancelable
* non-modal
* function for the preview of filters, too
* be fast
* be really easy to use

There are three possible mechanisms for notifying the view
of progress that I 
can see:

* pub/sub
* sending events
* emitting signals

pub/sub is very heavy weight; events have as a disadvantage
that we need a 
unique event id for our custom events (which may clash) and
for signals/slots 
we need QObjects.

I'm not sure how to progress: we want to look at
ThreadWeaver and Thomas' 
threadable actions framework before doing anything. Other
ideas?

-- 
Boudewijn Rempt 
http://www.va
ldyas.org/fading/index.cgi
_______________________________________________
kimageshop mailing list
kimageshopkde.org
http
s://mail.kde.org/mailman/listinfo/kimageshop

> * not thread-safe
> * cannot handle more than one progressing action at the
same time
> * uses processEvents (which is dangerous)
> * costs us quite a bit of cpu
actually the cpu cost mostly came from the repaint of the
progress bar. I said 
came, because sebastian has made a patch in 1.6 that have
make the whole 
process to be a drop water in the sea, for the gaussian blur
filter it's less 
than 1% of the time, and for the invert filter, it's lost in
the noise (same 
for more expensive filter like cimg).

That's said, all other points are valid.


> We need to replace it, therefore. The list of problems
is very nearly the
> list of requirements for the replacement:
>
> * threadsafe (should be able to handle updates from
different threads
> within the same action and still show a continuous
progress towards 100%) *
> be able to handle more than one concurrent action
> * be safe
> * be cancelable
> * non-modal
> * function for the preview of filters, too
> * be fast
> * be really easy to use
* algorithms must be able to call one other and the correct
progress should be 
display, for instance, the unsharp mask is composed of two
operations, first 
bluring, then a diff between the blured image and the
original one. The 
progress bar should at least go from 0 to 50% for the first
operation, and 
from 50% to 100% when doing the second operation (actually
it's more 0 to 80% 
and 80% to 100%, but you understand what I mean).

-- 
--- Cyrille Berger ---
_______________________________________________
kimageshop mailing list
kimageshopkde.org
http
s://mail.kde.org/mailman/listinfo/kimageshop

On Friday 20 October 2006 16:34, Boudewijn Rempt wrote:
> Currently, we use an event based progress architecture,
with vestiges of
> the old publish/subscribe architecture. This
architecture has a couple of
> big problems

Here is a first draft;

You create one ProgressUpdater for the progressBar thats
already in your Gui 
and keep that instance around for as long as you want.

ProgressUpdater  *pu = new ProgressUpdater (widget);

For each action that has progress updating you do a;

pu->start(100);
Updater updater = pu->startSubtask();
where you can do things like:
updater.forward(10); // adds 10 percent to the progress of
this subtask.

You can have multiple Updater instances around if you have
different subtasks. 
So having a filter that does 3 things means you end up with
3 Updater 
instances which you can pass to your filter. The filter can
manipulate the 
Updater from any thread.
When one Updater has reached 100% done, in this example the
progressBar will 
show 33%.

I'll continue hacking on this for now. 
-- 
Thomas Zander
_______________________________________________
kimageshop mailing list
kimageshopkde.org
http
s://mail.kde.org/mailman/listinfo/kimageshop

> pu->start(100);
> Updater updater = pu->startSubtask();
> where you can do things like:
> updater.forward(10); // adds 10 percent to the progress
of this subtask.
How does the substask tell how much it cost ? Or is it up to
the main filter 
to know that the overall cost ?

> I'll continue hacking on this for now. 
cool 
-- 
--- Cyrille Berger ---
_______________________________________________
kimageshop mailing list
kimageshopkde.org
http
s://mail.kde.org/mailman/listinfo/kimageshop

On Saturday 21 October 2006 18:57, Cyrille Berger wrote:
> > pu->start(100);
> > Updater updater = pu->startSubtask();
> > where you can do things like:
> > updater.forward(10); // adds 10 percent to the
progress of this subtask.
>
> How does the substask tell how much it cost ? Or is it
up to the main
> filter to know that the overall cost ?

The startSubtask() I used above is using the default weight
argument of 1.
If you have 3 tasks and the 3th is just a small one you can
create them like 
this:
Updater smooth = pu->startSubtask(5);
Updater scale = pu->startSubtask(5);
Updater cleanup = pu->startSubtask(1);

Each individually still ranges from 0-100, but the effect
will be scaled by 
the weight of each individual subtask in the total
progress-count.

I do, however, require that all subtasks are created before
you start work. I 
assume thats not an issue.
-- 
Thomas Zander
_______________________________________________
kimageshop mailing list
kimageshopkde.org
http
s://mail.kde.org/mailman/listinfo/kimageshop

On Saturday 21 October 2006 17:58, Thomas Zander wrote:

> I'll continue hacking on this for now. 

Wheee!
-- 
Boudewijn Rempt 
http://www.va
ldyas.org/fading/index.cgi
_______________________________________________
kimageshop mailing list
kimageshopkde.org
http
s://mail.kde.org/mailman/listinfo/kimageshop

On Saturday 21 October 2006 17:58, Thomas Zander wrote:

Hi,

> ProgressUpdater  *pu = new ProgressUpdater (widget);
>
> For each action that has progress updating you do a;
>
> pu->start(100);
> Updater updater = pu->startSubtask();
> where you can do things like:
> updater.forward(10); // adds 10 percent to the progress
of this subtask.

You may want to have ProgressUpdater and Updater typed to
one interface, so 
that you can use them interchangeably. And the Updater could
also get a 
textual description.

FWIW, Eclipse uses a very similar interface (see
ProgressMonitor and 
SubProgressMonitor conforming to IProgressMonitor).

Cheers,
Carsten
_______________________________________________
kimageshop mailing list
kimageshopkde.org
http
s://mail.kde.org/mailman/listinfo/kimageshop