[Webkit-unassigned] [Bug 30442] Add helper methods to determine whether a transformation matrix is only scaled or translated

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=30442


Jakob Petsovits <jpetsovits at rim.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #41383|                            |review?, commit-queue?
               Flag|                            |
  Attachment #41327|0                           |1
        is obsolete|                            |
  Attachment #41327|review?, commit-queue?      |
               Flag|                            |




--- Comment #6 from Jakob Petsovits <jpetsovits at rim.com>  2009-10-18 10:46:58 PDT ---
Created an attachment (id=41383)
 --> (https://bugs.webkit.org/attachment.cgi?id=41383)
Add a mapsRectToRect() helper method to TransformationMatrix (try 2)

> But a rotated rectangle is still a rectangle.

It's not a "Rect" (IntRect, FloatRect) though, so the function name is correct
- while the comment and commit message were slightly off this way, I changed
those to say "upright rectangle" instead of just "rectangle".

> And it's very possible that a
> matrix that returned true from the above function would still not preserve
> rectangularity. For instance, something other than 1 in [3][3] would fail.

Well, the corresponding code in multVecMatrix() (2D version, used by
mapPoint(), which is in turn used by mapQuad(), and that's used by mapRect())
goes like this:

double w = m_matrix[3][3] + x * m_matrix[0][3] + y * m_matrix[1][3];
if (w != 1 && w != 0) {
    resultX /= w;
    resultY /= w;
}

Assuming that [0][3] and [1][3] are 0 (which my method ensures), w is not
affected by the x and y coordinates, which means that similar input x/y values
will result in similar output values as well. For IntRects and FloatRects,
which feature similar x/y values for their edges, it means that even if [3][3]
is something other than 1 it will still result in an upright {Int,Float}Rect.
Personally I don't care whether I check for [3][3] or not, I just thought I'd
match the semantics with the function name.

> It seems like you are trying to create a low-level function that serves a very
> specific purpose but it's not clear what that purpose is. If what you want is
> some optimized way to do bounds or intersection checking, perhaps it would be
> better to add that function to TransformationMatrix rather than a function like
> this.

Nope, it's not meant to do anything more lower-level than checking if I can
avoid using (and cumbersome checking of) Quads.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.