Usage of setCurrentNodeLocked()

[Sven Langkamp]

On Fri, Sep 24, 2010 at 7:36 PM, Dmitry Kazakov <dimula73 at gmail.com> wrote:

>
> I think we could solve that by mixing both concepts. I propose the
>> following:
>>
>> We introduce a new class KisNodeActionScheduler that could be in KisImage
>> or similar central place. All node actions would have to go through this
>> class. The scheduler would manage the node queues and distribute node
>> actions to the queues. The class is protected by a mutex, so we don't get
>> race conditions there.
>>
>
> I think, to be more productive we can discuss and criticize some particular
> model of this subsystem. We can use a draft that i proposed it the
> beginning:
>
> http://dimula73.narod.ru/ToolJobsQueue.xmi
>
>
>> For adding job I suggest that node actions can added with some type
>> parameter. The action can either be marked as "queue" or "blocking" (names
>> are need a better choice). In case of "queue" the scheduler simply adds the
>> job to the end of queue. The "blocking" type would be used by interactive
>> tools. In that case the scheduler only add the action if the queue is empty.
>> The method that adds the action returns the result of that, so that the
>> tools will be informed if the action they wanted to add wasn't accepted and
>> don't proceed.
>>
>
> May i ask a question? ;) What the tool is supposed to do if it got a reply
> that it's stroke has *not* been added to the queue? Just drop it or what?
>
> see "Rejected Stroke Case" diagram.
>

It should show a warning that the node is busy and not even start the
stroke.


>
> Speaking truly I'm against dropping any actions made by the user. That is
> the way Gimp works. If you want to paint two gradients and you do it fast
> enough to do the second stroke before the first has finished it's
> calculation, the second one will be dropped. I think it is the worst thing
> we can suggest for a user =)
>
> The case when two types of strokes (e.g. gradient and brush) are mixed in
> the queue. I think there is nothing bad in it. The model i proposed will not
> start execution of a brush stroke, before the stroke of the gradient is
> finished.
>
> see "Two types of strokes" diagram.
>

There are non-interactive actions like filters and interactive action like
freehand. While the first can be queued the later can not. Gradient is
somewhere between both.

For me a freehand action is everything between initPaint and endPaint. And
in the freehand to I expect to see what is going on. Now if there is a
filter running on the node and put a freehand action behind the filter in
the queue you don't see what you are painting.



> I think cancel and undo is tricky. I think we should limit cancel to the
>> last action that was added, because otherwise we could get into some crazy
>> cases where we cancel some action in the middle of a queue. Undo commands
>> need to be added in the order that the user added the action. Currently we
>> add undo commands after the processing is finished which means that the
>> order of the undo commands depends on the time the actions need to process.
>>
>
> Well, the queue guarantees that two different strokes will never be
> executing simultaneously. So the problem of undo is not actual here, i
> guess.
>

Not exactly, I'm wondering if we are talking about the same thing. There is
one queue per node which means that several actions are executed at the same
time. There could be a filter running on layer 1, while you are painting on
layer 2. So different actions can finish at the same time, so you need to
check the order in which they are added to the undo stack.


> Cancel, yes, we can do it in two different ways:
> 1) Esc-key cancels all the contents of the queue.
> 2) Esc-key removes the last stroke from the queue. So to clear the queue,
> you will have to press Esc several times.
>
> Actually, i don't know which variant is better.
>

Here we have to care for several queue too. Scale image would start several
seperate node actions in different node queues. If you want to cancel that
you have to cancel every node action which might be already applied.


>
>
> The scheduler should also be able to pause action. This isn't that urgent,
>> but should be added in future releases. Imagine a case where you have
>> started a very computing intense filter on one layer and want to paint on
>> another layer. In that case the scheduler would pause the filter while you
>> are painting to keep it snappy.
>>
>
> I think this will be very weird "feature" from interactions design point of
> view. Noone will pause any actions manually, while they are painting
> something. More than that, it is not always possible (simply technically) to
> pause an action and start working on the same image. The thing that is
> possible, i think, is to have priorities of the tools and sort the queue,
> but it can lead to really weird and unexpected results from the UI point of
> view.
>

This would be done automatically. With the example from above the brush
stoke would get choppy because the CPU is busy processing the filter.
Pausing an action is a bit difficult, but at least you could stop other
queues.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kimageshop/attachments/20100924/addd0485/attachment.htm