cc: Use ui/gfx geometry types for the CCRenderPass and CCDrawQuad classes.

cc: Use ui/gfx geometry types for the CCRenderPass and CCDrawQuad classes.

We use these geometry types for CCDrawQuad types and in CCRenderPass, and so
we also make use of them in the CCRenderer classes.

A minor number of copies back to cc:: (WebCore) geometry types do occur in
the renderer implementations for now until we migrate the rest of the compositor.

Covered by existing tests.

BUG=152473
R=enne,jamesr

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=163142

[danakj, 2012-09-26 22:26:45]

PTAL

This will allow us to remove WebCore types from all CCRenderPass and dependency
headers in a way that pushes us closer to GTFO completion instead of temporarily
using Web* types.

[enne (OOO), 2012-09-28 16:59:55]

We use these types a lot.  Is there a reason to have a separate ccmath namespace
here?

If it's possible, I'd prefer to have them all in cc and just replace the stubs,
so we don't have to prefix them all over the place.

[aelias_OOO_until_Jul13, 2012-09-28 18:33:22]

On http://code.google.com/p/chromium/issues/detail?id=147395 there seems to be
agreement that we'll use ui::gfx types instead, so is this obsolete?

I think math type switching is not required for ubercomp FWIW, with the sole
exception of the IntRect and FlaotRect held by class RenderPass proper.

[danakj, 2012-09-28 19:38:02]

On 2012/09/28 18:33:22, aelias wrote:
> On http://code.google.com/p/chromium/issues/detail?id=147395 there seems to be
> agreement that we'll use ui::gfx types instead, so is this obsolete?
> 
> I think math type switching is not required for ubercomp FWIW, with the sole
> exception of the IntRect and FlaotRect held by class RenderPass proper.

RenderPass.h includes DrawQuad.h so it is required. We can't have scoped_ptr for
a DrawQuad without including its header.

There are workarounds, I started an email with jamesr/piman since we were
discussing and I should have CCd you on it, sorry. Lemme do that.

Anyhow, I'm going to redo this patch with ui/gfx types yes.

[tfarina, 2012-09-28 19:39:30]

http://codereview.chromium.org/10984053/diff/2001/cc/math/clamp.h
File cc/math/clamp.h (right):

http://codereview.chromium.org/10984053/diff/2001/cc/math/clamp.h#newcode8
cc/math/clamp.h:8: #include "cc/math/clamp.h"
we are self including here?

http://codereview.chromium.org/10984053/diff/2001/cc/math/clamp.h#newcode9
cc/math/clamp.h:9: #include "cc/math/int_point.h"
I guess unused in this header file.

http://codereview.chromium.org/10984053/diff/2001/cc/math/clamp.h#newcode15
cc/math/clamp.h:15: private:
private sections after public

the other we usually follow is:
public:
protected:
private:

http://codereview.chromium.org/10984053/diff/2001/cc/math/clamp.h#newcode30
cc/math/clamp.h:30: };
DISALLOW_IMPLICIT_CONSTRUCTORS

http://codereview.chromium.org/10984053/diff/2001/cc/math/int_point.h
File cc/math/int_point.h (right):

http://codereview.chromium.org/10984053/diff/2001/cc/math/int_point.h#newcode13
cc/math/int_point.h:13: public:
if this were to follow chromium coding style, this would have to be indented one
space.

http://codereview.chromium.org/10984053/diff/2001/cc/math/int_point.h#newcode34
cc/math/int_point.h:34: int m_x;
and thus this would have to be |x_|

http://codereview.chromium.org/10984053/diff/2001/cc/math/int_point.h#newcode54
cc/math/int_point.h:54: } // namespace ccmath
}  // namespace ccmatch
 ^
two spaces between }  and  //

[tfarina, 2012-09-28 19:41:11]

On Fri, Sep 28, 2012 at 4:39 PM,  <[email protected]> wrote:
> http://codereview.chromium.org/10984053/diff/2001/cc/math/clamp.h#newcode15
> cc/math/clamp.h:15: private:
> private sections after public
>
> the other we usually follow is:
ops, s/other/order

-- 
Thiago

[jamesr1, 2012-09-28 19:47:43]

On Fri, Sep 28, 2012 at 12:38 PM, <[email protected]> wrote:

> On 2012/09/28 18:33:22, aelias wrote:
>
>> On
http://code.google.com/p/**chromium/issues/detail?id=**147395<http://code.goo...
seems to be
>> agreement that we'll use ui::gfx types instead, so is this obsolete?
>>
>
>  I think math type switching is not required for ubercomp FWIW, with the
>> sole
>> exception of the IntRect and FlaotRect held by class RenderPass proper.
>>
>
> RenderPass.h includes DrawQuad.h so it is required. We can't have
> scoped_ptr for
> a DrawQuad without including its header.
>

You can have a member scoped_ptr<T> for a forward declared T so long as the
destructor and constructor are not inline (I was a bit confused about this
earlier, sorry).

>
> There are workarounds, I started an email with jamesr/piman since we were
> discussing and I should have CCd you on it, sorry. Lemme do that.
>
> Anyhow, I'm going to redo this patch with ui/gfx types yes.
>
>
https://codereview.chromium.**org/10984053/<https://codereview.chromium.org/1...
>

[danakj, 2012-09-28 22:48:37]

PTAL. I've switch all the Quads/RenderPass structures to ui/gfx types this time.

Some minimal changes in ui/gfx took place:
1) Removed iffy flooring conversion from Float types to Int types.
2) Added operators to convert from Int to Float types so you can do things like
add a Point to a PointF and viceversa.
3) Added operator+ and operator- for point types. This had to be done in both
Point and PointF headers to allow (Point+PointF) to compile.
4) Move the PointF::~PointF() destructor to the .cc file to be consistent with
other types.
5) Remove the unimplemented PointF::PointF(Point) constructor from the header.
6) Add a copy constructor for PointF and Point so that the PointBase::Add() and
PointBase::Subtract() methods compile.

[jamesr, 2012-09-28 22:50:40]

On 2012/09/28 22:48:37, danakj wrote:
> PTAL. I've switch all the Quads/RenderPass structures to ui/gfx types this
time.
> 
> Some minimal changes in ui/gfx took place:
> 1) Removed iffy flooring conversion from Float types to Int types.
> 2) Added operators to convert from Int to Float types so you can do things
like
> add a Point to a PointF and viceversa.
> 3) Added operator+ and operator- for point types. This had to be done in both
> Point and PointF headers to allow (Point+PointF) to compile.
> 4) Move the PointF::~PointF() destructor to the .cc file to be consistent with
> other types.
> 5) Remove the unimplemented PointF::PointF(Point) constructor from the header.
> 6) Add a copy constructor for PointF and Point so that the PointBase::Add()
and
> PointBase::Subtract() methods compile.

Let's do the ui/gfx changes as a separate patch.

[danakj, 2012-09-28 22:53:58]

On 2012/09/28 22:50:40, jamesr wrote:
> Let's do the ui/gfx changes as a separate patch.

k! https://codereview.chromium.org/10993094

[danakj, 2012-09-29 00:28:19]

I double checked and fixed up all the changes with regard to
gfx::Rect::Intersect and Union and Scale behaviour (they return the new value
instead of modifying the existing struct).

Also, removed cc:: prefix for IntRect/IntSize etc to reduce patch noise where
IntSize etc was already being used.

I kept cc:: prefix for cases where we are temporarily casting from gfx::Foo to
cc::Foo ie WebCore::Foo so that we can find those places and remove the
constructor call entirely in the future. IntSize(foo) is ambiguous if we needed
a cast from foo to an IntSize before or not. cc::IntSize(foo) only exists in
cases where we can remove the cast once we are using gfx:: stuff.

This depends on https://codereview.chromium.org/10993094/ so it won't compile
until that lands.

[enne (OOO), 2012-10-05 16:25:01]

I know you've done all the hard work of adding ToFoo() already, but I really
don't want to use gfx if it means that we don't get implicit int->float
conversions for our geometry types.

[danakj, 2012-10-11 17:50:46]

PTAL. This depends on http://codereview.chromium.org/11028127

[enne (OOO), 2012-10-11 18:46:46]

lgtm

[commit-bot: I haz the power, 2012-10-15 21:26:13]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/[email protected]/10984053/44001

[commit-bot: I haz the power, 2012-10-15 21:39:22]

Retried try job too often for step(s) base_unittests, browser_tests,
cacheinvalidation_unittests, check_deps, content_browsertests,
content_unittests, crypto_unittests, gpu_unittests, interactive_ui_tests,
ipc_tests, jingle_unittests, media_unittests, net_unittests, printing_unittests,
sandbox_linux_unittests, sql_unittests, sync_unit_tests, unit_tests

[commit-bot: I haz the power, 2012-10-15 21:43:31]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/[email protected]/10984053/48002

[commit-bot: I haz the power, 2012-10-15 23:18:37]

Sorry for I got bad news for ya.
Compile failed with a clobber build.
Your code is likely broken or HEAD is junk. Please ensure your
code is not broken then alert the build sheriffs.
Look at the try server FAQ for more details.

[commit-bot: I haz the power, 2012-10-20 00:11:42]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/[email protected]/10984053/88001

[commit-bot: I haz the power, 2012-10-20 04:12:45]

Change committed as 163142