Default pixel and paint device bounds

Sven Langkamp sven.langkamp at gmail.com
Sun Sep 12 14:05:39 CEST 2010


On Sun, Sep 12, 2010 at 2:01 PM, Sven Langkamp <sven.langkamp at gmail.com>wrote:

> On Sun, Sep 12, 2010 at 1:44 PM, Boudewijn Rempt <boud at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kimageshop/attachments/20100912/dad08adc/attachment.htm 


More information about the kimageshop mailing list