koffice/krita/ui/canvas

[Adam]

I just noticed, that the rectangle tool draws the temporary border  
thinner, than other tools (ellipse, star etc.) after Adrian's change. When  
drawing with the polyline tool horizontally or vertically, it's possible  
to make a thin or a thick border.

On Mon, 01 Feb 2010 12:08:07 +0100, Dmitry Kazakov <dimula73 at gmail.com>  
wrote:

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


-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/