On Sun, Sep 12, 2010 at 2:01 PM, Sven Langkamp <sven.langkamp@gmail.com> wrote:
On Sun, Sep 12, 2010 at 1:44 PM, Boudewijn Rempt <boud@valdyas.org> wrote:
On Sunday 12 September 2010, Marc wrote:
> Yesterday I fixed bug 245778 in the transform workers, though the
> problem might still appear in other places.
> Actually, the problem came from the fact that the first layer had a non
> transparent default pixel. In that case, KisPaintDevice's exactBounds
> and extent return defaultBounds (which is set to (0,0),(image width,
> image height)) : that isn't really what the transform workers expect
> when calling exactBounds.
> For now, the transform workers check whether the default pixel is
> transparent or not. If it isn't, then it uses the dataManager extent
> instead of paintDevice bounds.
> It might be good to consider changing the exactBounds() behaviour when
> default pixel is not transparent (sven wondered whether we could unite
> the default bounds with the data manager in that case).

I think that exactBounds is used in a number of different ways and that it makes sense to add a parameter to the function to manage the handling of non-transparent default pixel paint devices, something like

exactBounds(bool alwaysCalculate = false);

?

Or add an enum (normal extent, extent or defaultbounds, extent united with defaultbounds)
For the transform tool only the normal extent is needed, I think.


Unite might not be such a good idea for transform as there good be a very big layer with a default pixel, but only very little painted.