[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-kimageshop
Subject: Re: koffice/krita/ui/canvas
From: Adrian Page <adrian () pagenet ! plus ! com>
Date: 2010-01-31 22:27:08
Message-ID: 7070BB0A-F3EA-4CCC-AEC6-E75C63A2CB0D () pagenet ! plus ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On 31 Jan 2010, at 7:13PM, Dmitry Kazakov wrote:
> On Sun, Jan 31, 2010 at 2:53 AM, Adrian Page <> wrote:
> Dmitry Kazakov wrote:
> > I thing this should be reverted according to Qt's QRect tradition, i.e.
> > (5,7)->(5.0,7.0). Or change ALL the Krita's code that uses
> > QRectF::toAlignedRect() or QRectF(intRect) to a new type of conversion.
> > Other way we'll dig a deep grave for ourselves using two completely
> > different coordinate systems throughout the code.
>
> This is the way krita has worked for the last however many years.
>
> Well, not everywhere. Please take a look into KisImage::documentToIntPixel(). It \
> uses QRectF::toAlignedRect(). So it does just the opposite to what you are saying.
It gives the desired result - the smallest integer rectangle containing the QRectF. \
That's what we're after.
> KisPrescaledProjection and KisView are fully based on Qt's style. (It was based on \
> it even before my refactorings)
>
> The standard in graphics is that when you convert int to floating point you
> add 0.5, and you truncate when converting float to int. (5, 7) -> (5.5,
> 7.5) -> (5, 7).
>
> Not sure about "truncating", as you may get some losses, when converting rects. I \
> think rounding is much more stable. I remember i had many troubles in prescaled \
> projection without rounding.
No, you shouldn't need to round. If you are rounding, then you will be losing pixels \
when whatever number you're rounding is > x.0 and < x.5. Floor() and ceil() gives the \
stability without ever losing pixels, that's what toAlignedRect() is doing. And \
floor() is the the truncating bit (for points).
Adrian
[Attachment #5 (unknown)]
<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; \
-webkit-line-break: after-white-space; "><br><div><div>On 31 Jan 2010, at 7:13PM, \
Dmitry Kazakov wrote:</div><br class="Apple-interchange-newline"><blockquote \
type="cite"><div class="gmail_quote">On Sun, Jan 31, 2010 at 2:53 AM, Adrian Page \
<span dir="ltr"><></span> wrote:<br><blockquote class="gmail_quote" \
style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; \
border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: \
solid; padding-left: 1ex; position: static; z-index: auto; "><div class="im"> Dmitry \
Kazakov wrote:<br> > I thing this should be reverted according to Qt's QRect \
tradition, i.e.<br> > (5,7)->(5.0,7.0). Or change ALL the Krita's code that \
uses<br> > QRectF::toAlignedRect() or QRectF(intRect) to a new type of \
conversion.<br> > Other way we'll dig a deep grave for ourselves using two \
completely<br> > different coordinate systems throughout the code.<br>
<br>
</div>This is the way krita has worked for the last however many \
years.</blockquote><div><br></div><div>Well, not everywhere. Please take a look \
into KisImage::documentToIntPixel(). It uses QRectF::toAlignedRect(). So it does \
just the opposite to what you are saying.</div></div></blockquote><div><br></div>It \
gives the desired result - the smallest integer rectangle containing the QRectF. \
That's what we're after.</div><div><br><blockquote type="cite"><div \
class="gmail_quote"> <div>KisPrescaledProjection and KisView are fully based on Qt's \
style. (It was based on it even before my \
refactorings)</div><div><br></div><div> </div><blockquote class="gmail_quote" \
style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> \
The standard in graphics is that when you convert int to floating point you<br> \
add 0.5, and you truncate when converting float to int. (5, 7) -> (5.5,<br> 7.5) \
-> (5, 7).</blockquote><div><br></div><div>Not sure about "truncating", as you may \
get some losses, when converting rects. I think rounding is much more stable. I \
remember i had many troubles in prescaled projection without \
rounding.</div></div></blockquote><div><br></div><div>No, you shouldn't need to \
round. If you are rounding, then you will be losing pixels when whatever number \
you're rounding is > x.0 and < x.5. Floor() and ceil() gives the stability \
without ever losing pixels, that's what toAlignedRect() is doing. And floor() \
is the the truncating bit (for \
points).</div><div><br></div></div><div>Adrian</div><div><br></div></body></html>
_______________________________________________
kimageshop mailing list
kimageshop@kde.org
https://mail.kde.org/mailman/listinfo/kimageshop
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic