<div class="gmail_quote">On Fri, Sep 24, 2010 at 7:36 PM, Dmitry Kazakov <span dir="ltr"><<a href="mailto:dimula73@gmail.com" target="_blank">dimula73@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br><div class="gmail_quote"><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 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><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" target="_blank">http://dimula73.narod.ru/ToolJobsQueue.xmi</a><br>
</div><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><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></div></div></blockquote><div><br>It should show a warning that the node is busy and not even start the stroke.<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><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></div></div></blockquote><div><br>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.<br>
<br>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. <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></div><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><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></div></div></blockquote><div>
<br>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.<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>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.</div>
</div></blockquote><div><br>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.<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> <br><br></div><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><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></blockquote></div><br>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.<br>