<br><br><div class="gmail_quote">On Mon, Feb 1, 2010 at 1:27 AM, Adrian Page <span dir="ltr"><></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div style="word-wrap: break-word;"><br><div><div class="im"><div>On 31 Jan 2010, at 7:13PM, Dmitry Kazakov wrote:</div><br><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: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div>
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></div>It gives the desired result - the smallest integer rectangle containing the QRectF. That's what we're after.</div></div></blockquote><div><br>No, it doesn't. Because truncating and adding 0.5 is not stable over scaling. Just right over the thing we do in KisImage.<br>
<br>Example:<br><br>QPointF convertToQPointF(QPoint pt) {<br> return QPointF((pt.x()+0.5)*2, (pt.y()+0.5)*2);<br>}<br><br>QRectF convertToQRectF(QRect rc) {<br> return QRectF(convertToQPointF(rc.topLeft()), convertToQPointF(rc.bottomRight()));<br>
}<br><br>void main()<br>{<br> QRect rect(0,0,6,4);<br> qDebug()<<"intRect:"<<rect<<rect.topLeft()<<rect.bottomRight();<br><br> QRectF floatRect(convertToQRectF(rect));<br> qDebug()<<"floatRect:"<<floatRect<<floatRect.topLeft()<<floatRect.bottomRight();<br>
<br> QRect alignedRect(floatRect.toAlignedRect());<br> qDebug()<<"alignedRect:"<<alignedRect<<alignedRect.topLeft()<<alignedRect.bottomRight();<br>}<br><br>The result will be the following:<br>
intRect: QRect(0,0 6x4) QPoint(0,0) QPoint(5,3)<br>floatRect: QRectF(1,1 10x6) QPointF(1, 1)QPointF(11, 7)<br>alignedRect: QRect(1,1 10x6) QPoint(1,1) QPoint(10,6)<br><br><br>That is surely NOT what we desired. (btw, this example is almost a piece code from KisImage)<br>
<br>What do i want to say? <br>1) If we decide to use Qt's style, we must not use these additional (+0.5) anywhere in the code. More than that, we can't even use bottomRight() function of QRect for scaling due to the "historical reasons" mentioned in Qt's documentation for QRect. We should scale width() and height() of the rect instead.<br>
<br>2) If we decide to stay with the majority of the flow, we should remove all the traces of QRectF from Krita's code, for not confusing coders and eliminate their temptation to use toAlignedRect().<br><br> <br></div>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div style="word-wrap: break-word;"><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.</div>
</div></div></blockquote><div><br>You won't loose anything if you use math for this =) You shouldn't add exactly 0.5. You should add (0.5-EPS), where EPS=1e-10.<br>In such a case you'll get stable scale operation and no pixels will be lost.<br>
<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div style="word-wrap: break-word;"><div><div> 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></div></blockquote></div><br>But not stable over scaling.<br clear="all"><br>-- <br>Dmitry Kazakov<br>