Patch for thumbnail update in layerbox

[Sven Langkamp]

On Tue, Sep 21, 2010 at 8:53 PM, Cyrille Berger <cberger at cberger.net> wrote:

> On Sunday 19 September 2010, Boudewijn Rempt wrote:
> > On Sunday 19 September 2010, Dmitry Kazakov wrote:
> > > I think adding parameters is the worst thing that we can do here =(
> >
> > Maybe it would be better to bite the bullet & not use the locked system
> to
> > hint for updates, but add a signal updated() to KisBaseNode that can be
> > emitted by tools when they are done.
> Yes I quite agree. Sounds like it is a workaround, that abuse an other
> workaround. The reason systemLock was added is because we didn't had a
> system
> to queue actions.
>
> This is why I also agree with Dmitry that systemLock should disappear one
> day.
>
> It should be replaced by a list of action that need to be applied on a
> node,
> and in a thread, the first action of that list is applied in thread, and
> tools
> only add new actions to that list. And some tools (or paintops) that needs
> an
> empty list (think the duplicate op) would simply be locked or prevented to
> paint (and show the "blocked" cursor).
>
> We basically have all the bricks to implement this with the
> ThreadApplicator
> framework, and the action recorder to provide the actions.
>

The problem I'm seeing with this is that the queue wouldn't just buffer for
a short time but is could take several seconds.
So you could start a filter that takes several seconds and while the filter
is running paint something and start another filter. Then Krita would
process your filter and show the outcome. You would basically paint blind
for some time. I don't know about you, but I can't predict what my final
painting looks like ;)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kimageshop/attachments/20100921/f2940333/attachment.htm