cc: Remove WebCore::FloatRect use from the compositor.

cc: Remove WebCore::FloatRect use from the compositor.

This replaces the last cases of FloatRect with gfx::RectF. It depends on the
IsExpressibleAsRect() method in https://codereview.chromium.org/11364054/ and
removes the stubs as well!

Covered by existing tests.

R=enne
BUG=147395

[danakj, 2012-11-02 18:03:01]

Present for you!

[enne (OOO), 2012-11-02 18:05:51]

lgtm

http://codereview.chromium.org/11369051/diff/1001/cc/cc.gyp
File cc/cc.gyp (left):

http://codereview.chromium.org/11369051/diff/1001/cc/cc.gyp#oldcode260
cc/cc.gyp:260: 'stubs/FloatRect.h',
\o/

http://codereview.chromium.org/11369051/diff/1001/cc/occlusion_tracker.cc
File cc/occlusion_tracker.cc (right):

http://codereview.chromium.org/11369051/diff/1001/cc/occlusion_tracker.cc#new...
cc/occlusion_tracker.cc:136: gfx::Rect transformedRect =
gfx::ToEnclosedRect(MathUtil::mapClippedRect(transform,
gfx::RectF(gfx::Rect(cc::IntRect(rects[i])))));
This is one heck of a transformation sequence of rect types.

[danakj, 2012-11-02 18:08:31]

ty :)

http://codereview.chromium.org/11369051/diff/1001/cc/occlusion_tracker.cc
File cc/occlusion_tracker.cc (right):

http://codereview.chromium.org/11369051/diff/1001/cc/occlusion_tracker.cc#new...
cc/occlusion_tracker.cc:136: gfx::Rect transformedRect =
gfx::ToEnclosedRect(MathUtil::mapClippedRect(transform,
gfx::RectF(gfx::Rect(cc::IntRect(rects[i])))));
On 2012/11/02 18:05:51, enne wrote:
> This is one heck of a transformation sequence of rect types.

Yeh :|

WebCore->cc::IntRect so we can convert to gfx.
But there's no conversion from cc::IntRect to RectF, and adding that makes other
places ambiguous. So.. yeh /o\

[commit-bot: I haz the power, 2012-11-02 19:36:54]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/danakj@chromium.org/11369051/1001

[commit-bot: I haz the power, 2012-11-02 19:37:07]

Failed to apply patch for cc/cc.gyp:
While running patch -p1 --forward --force --no-backup-if-mismatch;
  patching file cc/cc.gyp
  Hunk #1 FAILED at 257.
  Hunk #2 FAILED at 268.
  2 out of 2 hunks FAILED -- saving rejects to file cc/cc.gyp.rej

Patch:       cc/cc.gyp
Index: cc/cc.gyp
diff --git a/cc/cc.gyp b/cc/cc.gyp
index
15bcc695b3b3e47036d18d7c722c0e94085ccda2..1d850a56ab9756f65c2d768dbbee29a787f3bf49
100644
--- a/cc/cc.gyp
+++ b/cc/cc.gyp
@@ -257,7 +257,6 @@
       'sources': [
         '<@(cc_source_files)',
         'stubs/FloatPoint.h',
-        'stubs/FloatRect.h',
         'stubs/FloatSize.h',
         'stubs/IntPoint.h',
         'stubs/IntRect.h',
@@ -268,7 +267,6 @@
 
         'stubs/config.h',
         'stubs/float_point.h',
-        'stubs/float_rect.h',
         'stubs/float_size.h',
         'stubs/int_point.h',
         'stubs/int_rect.h',

[danakj, 2012-11-02 20:13:07]

On 2012/11/02 18:05:51, enne wrote:
> lgtm
> 
> http://codereview.chromium.org/11369051/diff/1001/cc/cc.gyp
> File cc/cc.gyp (left):
> 
> http://codereview.chromium.org/11369051/diff/1001/cc/cc.gyp#oldcode260
> cc/cc.gyp:260: 'stubs/FloatRect.h',
> \o/
> 
> http://codereview.chromium.org/11369051/diff/1001/cc/occlusion_tracker.cc
> File cc/occlusion_tracker.cc (right):
> 
>
http://codereview.chromium.org/11369051/diff/1001/cc/occlusion_tracker.cc#new...
> cc/occlusion_tracker.cc:136: gfx::Rect transformedRect =
> gfx::ToEnclosedRect(MathUtil::mapClippedRect(transform,
> gfx::RectF(gfx::Rect(cc::IntRect(rects[i])))));
> This is one heck of a transformation sequence of rect types.

Argh, this dark magic won't compile on mac/win due to IntRect/Rect implicit
conversion stuff.

Wdyt of combining this with https://codereview.chromium.org/11361072/ ?

[enne (OOO), 2012-11-02 20:27:42]

On 2012/11/02 20:13:07, danakj wrote:

> Wdyt of combining this with https://codereview.chromium.org/11361072/ ?

Let me review them separately, and you can land in any way that makes the most
sense to you.

You could also just do gfx::RectF(rects[i].x(), rects[i].y(), rects[i].width(),
rects[i].height()), and I suspect that would work too?

[danakj, 2012-11-02 20:34:19]

On 2012/11/02 20:27:42, enne wrote:
> On 2012/11/02 20:13:07, danakj wrote: of combining this with
https://codereview.chromium.org/11361072/ ?
> 
> Let me review them separately, and you can land in any way that makes the most
> sense to you.
> 
> You could also just do gfx::RectF(rects[i].x(), rects[i].y(),
rects[i].width(),
> rects[i].height()), and I suspect that would work too?

True, it would!