<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>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>
</div></div></blockquote><div><br>So you do suggest to drop a user's stroke, don' t you?<br>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? ;)<br>
<br>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.<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>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></div></blockquote><div><br>Ermm.. do you see any usecase for making a separate queue for every node? Speaking truly, i don't see any. My motivation:<br>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.<br>
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.<br><br>How i see this workflow:<br>* In most cases the user waits until his previous action has been finished. He waits voluntary, without any compulsion from the system. He just wants to see what he has done.<br>
* In some cases he may decide to do several strokes one right after the first one. E.g. he wants to paint a dashed line. He doesn't want to wait for every stroke, he just moves his stylus. If we decide to drop his strokes (because the brush he uses is really slow), he'll be really disappointed ;)<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>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></div></blockquote><div><br>Sounds weird.<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 class="im">
<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 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></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>
</blockquote></div><br>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.<br>
<br><br><br><br><br>-- <br>Dmitry Kazakov<br>