Updated Khronos GLES2 headers.

Updated Khronos GLES2 headers.

There was a type conflict between the previous, out of date headers and the more
recent ones included in ANGLE that was causing failures on 64-bit Windows.

BUG=326382
R=kbr@chromium.org, piman@chromium.org, raymes@chromium.org
TBR=robertphillips@google.com

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=241661

[bajones, 2013-12-13 19:33:45]

Please take a look

[piman, 2013-12-13 21:10:26]

lgtm

[Ken Russell (switch to Gerrit), 2013-12-13 22:06:14]

lgtm

[bajones, 2013-12-16 23:37:36]

brettw@: Could you take a look at the ppapi change? When uploading I got the
following error:

Missing PPAPI IDL for stable interface:
***************
  ppapi/c/ppb_opengles2.h
***************

But looking at similar cases in the past it seems this is safe to ignore for
this case, do you agree?

[bajones, 2013-12-17 00:54:21]

Adding a couple more ppapi owners in case @brettw is already on vacation.

[raymes, 2013-12-17 00:58:35]

I can't see the patch. Could you try uploading again?

On Tue, Dec 17, 2013 at 11:54 AM,  <bajones@chromium.org> wrote:
> Adding a couple more ppapi owners in case @brettw is already on vacation.
>
> https://codereview.chromium.org/99053007/

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[bajones, 2013-12-17 16:55:21]

On 2013/12/17 00:58:35, raymes wrote:
> I can't see the patch. Could you try uploading again?
> 
> On Tue, Dec 17, 2013 at 11:54 AM,  <mailto:bajones@chromium.org> wrote:
> > Adding a couple more ppapi owners in case @brettw is already on vacation.
> >
> > https://codereview.chromium.org/99053007/
> 
> To unsubscribe from this group and stop receiving emails from it, send an
email
> to mailto:chromium-reviews+unsubscribe@chromium.org.

Apologies, Rietveld has been cranky lately. Re-uploaded.

[raymes, 2013-12-17 23:18:57]

lgtm

On Wed, Dec 18, 2013 at 3:55 AM,  <bajones@chromium.org> wrote:
> On 2013/12/17 00:58:35, raymes wrote:
>>
>> I can't see the patch. Could you try uploading again?
>
>
>> On Tue, Dec 17, 2013 at 11:54 AM,  <mailto:bajones@chromium.org> wrote:
>> > Adding a couple more ppapi owners in case @brettw is already on
>> > vacation.
>> >
>> > https://codereview.chromium.org/99053007/
>
>
>> To unsubscribe from this group and stop receiving emails from it, send an
>
> email
>>
>> to mailto:chromium-reviews+unsubscribe@chromium.org.
>
>
> Apologies, Rietveld has been cranky lately. Re-uploaded.
>
> https://codereview.chromium.org/99053007/

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[commit-bot: I haz the power, 2013-12-18 21:28:55]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/bajones@chromium.org/99053007/80001

[bajones, 2013-12-18 21:40:28]

Committed patchset #4 manually as r241661.

[bajones, 2013-12-18 22:02:15]

A revert of this CL has been created in
https://codereview.chromium.org/106903014/ by bajones@chromium.org.

The reason for reverting is: Build errors..

[tomhudson, 2013-12-19 10:39:23]

NOT LGTM.

Please NEVER roll Skia forward without the Skia team's explicit OK; they have an
extensive test process they conduct before any roll, and it doesn't look like it
was followed here.

This is particularly problematic because rolling and then reverting DEPS breaks
Android development. The Chrome -> Android WebView infrastructure is a one-way
merge process that can't handle a git revert; nobody can build that branch until
Skia is rolled forward again.

[robertphillips, 2013-12-19 14:18:07]

Sorry about that Tom. We did know in this case (bajones even picked up
bungeman's changes).

Perhaps for another thread, but is there anything we can do when we're reverted
to restore sanity in Android WebView land (e.g., explicitly land a patch to put
DEPS back)?

[tomhudson, 2013-12-19 14:20:30]

On 2013/12/19 14:18:07, robertphillips wrote:
> Sorry about that Tom. We did know in this case (bajones even picked up
> bungeman's changes).

OK, given the revert for compile breakages and the fact that it hadn't been
through the Skia deps process and you weren't listed as a reviewer, it looked
uncoordinated.

> Perhaps for another thread, but is there anything we can do when we're
reverted
> to restore sanity in Android WebView land (e.g., explicitly land a patch to
put
> DEPS back)?

Torne caught it in time and was able to figure out how to hack around the
problem manually.

[bajones, 2013-12-19 17:41:21]

On 2013/12/19 10:39:23, tomhudson wrote:
> Please NEVER roll Skia forward without the Skia team's explicit OK; they have
an
> extensive test process they conduct before any roll, and it doesn't look like
it
> was followed here.

Apologies for the break in protocol. I was simply unaware that there was any
special procedure in place for Skia as opposed to the other third_party
dependencies. Thanks to Robert for explicitly reaching out to me to coordinate
the additional dependencies for this CL.

I've got a few more GPU-bot-only issues to sort out before we can try this again
(probably later today), and in that case I will explicitly communicate with the
Skia team to ensure the standard procedure is followed.

[robertphillips, 2013-12-19 17:50:01]

Another thing we could try is: 

land the Skia-side change behind a flag (e.g., SK_IGNORE_64BIT_OPENGL_CHANGES)
     This would be undefined in Skia so Skia would be using the new sizes
In tonight's/tomorrow's roll I update skia_library.gypi to define it for
Chromium
     So Chromium wouldn't be using the new sizes
Once the DEPS roll lands, you land your Chromium-side change but just remove the
define in skia_library.gypi rather then including a Skia DEPS roll

This would decouple the painful parts of a Skia DEPS roll from your
Chromium-side change but would cost us a day (to let the change works its way
into Chromium behind a flag)

[bajones, 2013-12-19 17:56:11]

On 2013/12/19 17:50:01, robertphillips wrote:
> Another thing we could try is: 
> 
> land the Skia-side change behind a flag (e.g., SK_IGNORE_64BIT_OPENGL_CHANGES)
>      This would be undefined in Skia so Skia would be using the new sizes
> In tonight's/tomorrow's roll I update skia_library.gypi to define it for
> Chromium
>      So Chromium wouldn't be using the new sizes
> Once the DEPS roll lands, you land your Chromium-side change but just remove
the
> define in skia_library.gypi rather then including a Skia DEPS roll
> 
> This would decouple the painful parts of a Skia DEPS roll from your
> Chromium-side change but would cost us a day (to let the change works its way
> into Chromium behind a flag)

I was actually thinking of the same thing last night. I'll post a CL with that
update ASAP!