<div class="gmail_quote">On Sun, Sep 12, 2010 at 1:44 PM, Boudewijn Rempt <span dir="ltr"><<a href="mailto:boud@valdyas.org">boud@valdyas.org</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;">
<div class="im">On Sunday 12 September 2010, Marc wrote:<br>
> Yesterday I fixed bug 245778 in the transform workers, though the<br>
> problem might still appear in other places.<br>
> Actually, the problem came from the fact that the first layer had a non<br>
> transparent default pixel. In that case, KisPaintDevice's exactBounds<br>
> and extent return defaultBounds (which is set to (0,0),(image width,<br>
> image height)) : that isn't really what the transform workers expect<br>
> when calling exactBounds.<br>
> For now, the transform workers check whether the default pixel is<br>
> transparent or not. If it isn't, then it uses the dataManager extent<br>
> instead of paintDevice bounds.<br>
> It might be good to consider changing the exactBounds() behaviour when<br>
> default pixel is not transparent (sven wondered whether we could unite<br>
> the default bounds with the data manager in that case).<br>
<br>
</div>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<br>
<br>
exactBounds(bool alwaysCalculate = false);<br>
<br>
?<br></blockquote><div><br>Or add an enum (normal extent, extent or defaultbounds, extent united with defaultbounds)<br>For the transform tool only the normal extent is needed, I think.<br><br> </div></div>