A first part of the layers/masks patch

[Boudewijn Rempt]

On Saturday 26 September 2009, Dmitry Kazakov wrote:

I'll just summarize point by point, I guess:

* original() vs paintDevice: ok.


> Yes, i can't reproduce it either now. I'll take a look at it. I always get
> empty dst device. Maybe the reason is that i pass it NULL selection?

Shouldn't make any difference.

> Well, the build and they run. But there are some fails. Most of them are
> connected to a design.

Hm -- can you give a list of those? And they need to be fixed, of course.

> Well, i'm going to write a todo list, so shortly now:
> 
> The refactoring will contain three patches.
> 1st: Fixes masks and introduces needRect/changeRect infrastructure for
> layers/masks.
> 2nd: Creates bottom-up recursive update strategy that works with
>  need/change rects
> 3rd: Using information, collected by new update strategy, creates an
>  "update scheduler", that ensures that no two threads use the same rect at
>  the same time.

Ok. But please aware that we're working towards a final release, so we're 
completely running out of time now: we need the projection fixed or we cannot 
release. Let's not waste time on side issues like the what-is-a-mask question, 
or whether there are too many or too few kactions declared. All that is 
completely unimportant compared to not being able to load a file anymore 
because KisProjection broke, and given the work you're doing now, nobody else 
can try and fix that issue, so that needs absolute focus.

> And only after the third patch projection will not have flickering anymore.
> The pyramid (more exactly, KisCanvas2) will use the same scheduler for
> threading scaling.

I'd even say that flickering is unimportant compared to actually having the 
image on screen.


> Not really =(

This is a matter of opintion, and I don't think it's fruitful anymore to 
debate this now, we need to get Krita ready for the next release.


re: layerbox d&d

> I don't think so. Doesn't it have an ability to control where we can drag
>  an item to?

That was our conclusion last time we tried to fix it. It's not a release 
blocker.

> > > [some design bugs]
> > > g) KisNodeManager::allowAsChild uses some silly string comparison
> > > algorithm. Why?! Every node has a specially designed method for this!
> >
> > Because that predates the newer method? You have to realize that the
> > Krita code is about 10 years old. You will find historical artefacts all
> > over the place.
> 
> Cleaning?

Yes, cleaning up is important. However, don't go around calling everything 
"design bug" all time :-).

> > No, they aren't. The gui in the layerbox defers to the nodemanager for
> > the executions of the user actions.
> 
> It breaks KAction paradigm. I've written about it before.

Sort of... I don't care much. I care that ultimately the same code is called. 
But it's also not a release blocker.

-- 
Boudewijn Rempt | http://www.valdyas.org