From kde-kimageshop Sun Sep 12 12:05:39 2010 From: Sven Langkamp Date: Sun, 12 Sep 2010 12:05:39 +0000 To: kde-kimageshop Subject: Re: Default pixel and paint device bounds Message-Id: X-MARC-Message: https://marc.info/?l=kde-kimageshop&m=128429354221536 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--===============1899230779==" --===============1899230779== Content-Type: multipart/alternative; boundary=0016363b917a5d507504900ecce8 --0016363b917a5d507504900ecce8 Content-Type: text/plain; charset=ISO-8859-1 On Sun, Sep 12, 2010 at 2:01 PM, Sven Langkamp wrote: > On Sun, Sep 12, 2010 at 1:44 PM, Boudewijn Rempt 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. --0016363b917a5d507504900ecce8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sun, Sep 12, 2010 at 2:01 PM, Sven Langkamp <= span dir=3D"ltr"><sven.langka= mp@gmail.com> wrote:
On Sun, Sep 12, 2010 at 1:44 P= M, 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 no= n
> transparent default pixel. In that case, KisPaintDevice's exactBou= nds
> and extent return defaultBounds (which is set to (0,0),(image width, > image height)) : that isn't really what the transform workers expe= ct
> 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 exte= nt
> 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 th= at 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 =3D false);

?

Or add an enum (normal extent, extent or d= efaultbounds, extent united with defaultbounds)
For the transform tool o= nly 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.
--0016363b917a5d507504900ecce8-- --===============1899230779== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ kimageshop mailing list kimageshop@kde.org https://mail.kde.org/mailman/listinfo/kimageshop --===============1899230779==--