koffice/krita/ui/canvas

[Dmitry Kazakov]

On Mon, Feb 1, 2010 at 1:27 AM, Adrian Page <> wrote:

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

No, it doesn't. Because truncating and adding 0.5 is not stable over
scaling. Just right over the thing we do in KisImage.

Example:

QPointF convertToQPointF(QPoint pt) {
    return QPointF((pt.x()+0.5)*2, (pt.y()+0.5)*2);
}

QRectF convertToQRectF(QRect rc) {
    return QRectF(convertToQPointF(rc.topLeft()),
convertToQPointF(rc.bottomRight()));
}

void main()
{
    QRect rect(0,0,6,4);
    qDebug()<<"intRect:"<<rect<<rect.topLeft()<<rect.bottomRight();

    QRectF floatRect(convertToQRectF(rect));

qDebug()<<"floatRect:"<<floatRect<<floatRect.topLeft()<<floatRect.bottomRight();

    QRect alignedRect(floatRect.toAlignedRect());

qDebug()<<"alignedRect:"<<alignedRect<<alignedRect.topLeft()<<alignedRect.bottomRight();
}

The result will be the following:
intRect: QRect(0,0 6x4) QPoint(0,0) QPoint(5,3)
floatRect: QRectF(1,1 10x6) QPointF(1, 1)QPointF(11, 7)
alignedRect: QRect(1,1 10x6) QPoint(1,1) QPoint(10,6)


That is surely NOT what we desired. (btw, this example is almost a piece
code from KisImage)

What do i want to say?
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.

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().



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

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.
In such a case you'll get stable scale operation and no pixels will be lost.



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

But not stable over scaling.

-- 
Dmitry Kazakov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kimageshop/attachments/20100201/9d87c368/attachment.htm