[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