Re: RFC: Sane rectangle class

On Friday 20 of March 2020, Regina Henschel wrote:
> Luboš Luňák schrieb am 19-Mar-20 um 16:13:
> >   Hello,
> >
> >   yes, this is about the tools::Rectangle nightmare of an API (in case
> > you don't know, it's this [1] ). I'm hunting an off-by-one error
> > somewhere in VCL, and it's hard to find it when I can't even tell which
> > parts of the code are right or wrong :(.
>
> These off-by-one problems occur earlier than in VCL. For example changes
> to maSnapRect when a shape is transformed by shear and rotation.

 My guess would be that by now such errors occur pretty much everywhere, 
because by now various hacks adding and subtracting 1 are spread all over the 
place.

> I see the problem not in tools::Rectangle itself, but in the fact, that
> it uses integer and not double. Using double makes width = right - left
> in all cases
> and would solve accuracy problems in manipulating shapes. 
> It would be up to renderer to do a suitable conversion to integer.

 I don't think using double magically solves everything. The same result can 
be obtained by defining 'width = right - left' with integers, and I think I 
can mis-count pixels as doubles just as well.

> and would solve accuracy problems in manipulating shapes. 
> It would be up to renderer to do a suitable conversion to integer.

 Do you have an estimate how big portion of code actually requires such 
accuraccy? I'd expect that using floats for everything would just complicate 
most of code for no real gain.

> You can already use getWidth() instead of GetWidth(). A new kind of
> rectangle does not solve the problem, that you have to examine each use,
> whether including or excluding the edge is better.

 I know I can use either getWidth() or GetWidth(), but that's exactly why 
tools::Rectangle is a problem, because it even encourages the confusion.

-- 
 Luboš Luňák
 l.lunak@collabora.com