[webkit-dev] Int/FloatPoint and Int/FloatSize

[Shawn Singh]

Personally I like the idea of removing the subtraction operator  (point
minus point returns size) and make it explicit.

*** However ***, if we change the data type of objects from Size to Point,
we have to be careful to check whether they are ever mapped by transforms.
  In particular, Points use a homogeneous coordinate of w=1, while Size
(and conceptual vectors) use homogeneous coordinates of w=0.

Some more thinking out loud -

Pros of making a separate vector class:
  - avoids the mismatch in Size or Point APIs
  - avoids the mismatch in homogeneous coordinate w usage
  - would allow us more compile-time safety in usage of math objects, i.e.
doing an operation that doesn't make sense could cause a type-mismatch
error.

Cons of making a separate vector class:
  - "offsets" are sometimes treated as relative point locations, and other
times treated as vectors that can be added to points.  Deciding when to use
which one could become just as confusing as using Point vs Size is right
now.



On Thu, Jan 3, 2013 at 10:00 AM, Levi Weintraub <leviw at google.com> wrote:

> Hi Steve,
>
> When converting the old tx/ty paint offsets to use IntPoint and IntSize
> (later LayoutPoint/Size) we had some discussion around this. Darin Adler
> wrote some good advice here:
> https://bugs.webkit.org/show_bug.cgi?id=61562#c2 -- quoting:
> "It’s hard to tell points and sizes apart when we have nested coordinate
> systems. The distance from the top left to a rect is a “size”, yet it’s
> expressed as an origin point. I think that whenever we can’t decide, we
> should use IntPoint, and we should use IntSize only when it’s clearly the
> size of something, not just a distance (a point described relative to
> another point)."
>
> Cheers,
> -Levi
>
>
> On Wed, Jan 2, 2013 at 11:21 PM, Steve Block <steveblock at chromium.org>wrote:
>
>> Hi webkit,
>>
>> I was hoping that somebody could clarify the policy regarding the
>> correct use of Int/FloatPoint vs Int/FloatSize.
>>
>> It seems that xxxPoint is consistently used to represent a position,
>> which makes sense. However, when representing the position of one
>> point relative to another, both xxxPoint and xxxSize are used, which
>> seems inconsistent. I'd expect that xxxPoint should be used for this
>> case of a relative position, since its x(), y() and length() methods
>> make more sense than the width() and height() methods of xxxSize.
>> However, the operators [1] for subtracting one xxxPoint from another
>> encourage the use of xxxSize. I recognize that in some situations, you
>> need really do want to represent the difference between two points as
>> an area or size, but this seems the less common case, and it might be
>> better to make it more explicit [2].
>>
>> My questions are ...
>> - What (if any) is the correct policy?
>> - Would people welcome changes to encourage that policy?
>>
>> Thanks,
>> Steve
>>
>> [1] eg 'inline FloatSize operator-(const FloatPoint&, const FloatPoint&)'
>> [2] Perhaps something like 'static FloatSize
>> FloatSize::fromCornerPoints(const FloatPoint&, const FloatPoint&)'.
>> _______________________________________________
>> webkit-dev mailing list
>> webkit-dev at lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo/webkit-dev
>>
>
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20130103/b7c32741/attachment.html>