<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="gmail_quote"><div>I think we could solve that by mixing both concepts. I propose the following:<br>
<br>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.<br>
</div></div></blockquote><div><br>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: <br><br><a href="http://dimula73.narod.ru/ToolJobsQueue.xmi">http://dimula73.narod.ru/ToolJobsQueue.xmi</a><br>
</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="gmail_quote"><div>
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.<br>
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.<br></div></div></blockquote><div><br>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?<br>
<br>see "Rejected Stroke Case" diagram.<br><br><br>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 =)<br>
<br>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.<br>
<br>see "Two types of strokes" diagram.<br><br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="gmail_quote">
<div>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.<br>
</div></div></blockquote><div><br>Well, the queue guarantees that two different strokes will never be executing simultaneously. So the problem of undo is not actual here, i guess. <br><br>Cancel, yes, we can do it in two different ways:<br>
1) Esc-key cancels all the contents of the queue.<br>2) Esc-key removes the last stroke from the queue. So to clear the queue, you will have to press Esc several times.<br><br>Actually, i don't know which variant is better.<br>
<br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="gmail_quote"><div>
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.<br>
</div></div></blockquote><div><br>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.<br>
</div></div><br clear="all"><br>-- <br>Dmitry Kazakov<br>