<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>