Usage of setCurrentNodeLocked()

[Boudewijn Rempt]

On Saturday 25 September 2010, Dmitry Kazakov wrote:
> > 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.
> >
> 
> So you do suggest to drop a user's stroke, don' t you?
> Btw, when you are painting with a big slow brush, you don't see what you are
> painting as well. Maybe, we should drop such a stroke as well? ;)

Let's not pull things into the realm of the ridiculous. The problem with big, slow brushes have nothing to do with this issue, but are problems of the big slow brush that should be optimized until it becomes a big, fast brush.

I am in agreement with Sven here: if a user starts painting, feedback needs to be immediate, so the freehand tool should not be accessible until the queue for that node is empty.

> The only usecase for such a blocking, i think, is mixing some global image
> commands with tools, e.g. mixing Resize Image and Freehand Tool. So Resize
> Image should be blocking. But no blocking should happen for pure tools. We
> should respect what the user has done, and don't throw it away.

I have to disagree with you here: while it's fine to queue a couple of filters or gradients or transforms, while they are running we should not be queing strokes. You can only paint if you have direct visual feedback.

> Ermm.. do you see any usecase for making a separate queue for every node?
> Speaking truly, i don't see any. My motivation:
> 1) It is really irritating, when you are trying to paint and your image is
> constantly flickering. So in most cases a human will wait until everything
> calms down and continues to paint after that. So the order of updates is not
> very important.
> 2) I don't think that the workflow of an artist is parallelizable. That
> means, you have to see what you've already done, and only then go on
> working.

Well, here I agree with you. We lock down per node because we don't have a queue, so the user can at least do something in another node and the the gui remains responsive. But if we have queuing, the only thing we have to do is block the painting tools while the queue is not empty.

> Well, again. I don't see any reason in painting on not-fully updated images
> except dashed-line example. Humans are not machines. More than that, it is
> really tricky process to switch to another layer while the previous tool
> hasn't finished yet, look at not-finished image, decide what you are going
> to paint here and paint it. And all that should be done while your CPU is
> under 100% load.

So, let's block the painting tools while the queue is not empty.

-- 
Boudewijn Rempt | http://www.valdyas.org
Ceterum censeo lapsum particulorum probae delendum esse