Set use_skia=1 by default

Set use_skia=1 by default

More background info at http://code.google.com/p/chromium/issues/detail?id=101731 ('re-enable use_skia by default')
BUG=101731
Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=108110

[epoger, 2011-10-31 19:31:10]

When I first ran this through the trybots, I saw a bunch of failures in
mac_layout and mac_layout_rel.

Now I am running both this and a "control group" CL (
http://codereview.chromium.org/8384016 ) against the mac_layout trybot, to see
how the results differ depending on the inclusion of this change.

[epoger, 2011-11-01 14:06:18]

On 2011/10/31 19:31:10, epoger wrote:
> When I first ran this through the trybots, I saw a bunch of failures in
> mac_layout and mac_layout_rel.
> 
> Now I am running both this and a "control group" CL (
> http://codereview.chromium.org/8384016 ) against the mac_layout trybot, to see
> how the results differ depending on the inclusion of this change.

I now understand the trybot results I'm seeing, and they are OK.  I believe this
CL is ready for review and submission.

More detail: 

In the "control" trybot (whitespace only change), there were 500+ errors in
webkit_tests but just one error in webkit_gpu_tests.

In the trybot for this CL, there were just a few errors in webkit_tests but 74
in webkit_gpu_tests.

If you look at the stdio for each of these, you can see the problem: the trybots
are evaluating webkit_tests against the "chromium-mac-snowleopard" port (i.e.
Skia), but evaluating webkit_gpu_tests against the
"chromium-gpu-cg-mac-snowleopard" port (CG).

I need to fix the trybot to evaluate against the Skia port in both cases.  Once
I do that (in a separate CL from this one), the trybots will find just a few
errors in webkit_tests and just one error in webkit_gpu_tests.

[joth, 2011-11-01 14:32:10]

On 2011/11/01 14:06:18, epoger wrote:
> On 2011/10/31 19:31:10, epoger wrote:
> > When I first ran this through the trybots, I saw a bunch of failures in
> > mac_layout and mac_layout_rel.
> > 
> > Now I am running both this and a "control group" CL (
> > http://codereview.chromium.org/8384016 ) against the mac_layout trybot, to
see
> > how the results differ depending on the inclusion of this change.
> 
> I now understand the trybot results I'm seeing, and they are OK.  I believe
this
> CL is ready for review and submission.
> 
> More detail: 
> 
> In the "control" trybot (whitespace only change), there were 500+ errors in
> webkit_tests but just one error in webkit_gpu_tests.
> 
> In the trybot for this CL, there were just a few errors in webkit_tests but 74
> in webkit_gpu_tests.
> 
> If you look at the stdio for each of these, you can see the problem: the
trybots
> are evaluating webkit_tests against the "chromium-mac-snowleopard" port (i.e.
> Skia), but evaluating webkit_gpu_tests against the
> "chromium-gpu-cg-mac-snowleopard" port (CG).
> 
> I need to fix the trybot to evaluate against the Skia port in both cases. 
Once
> I do that (in a separate CL from this one), the trybots will find just a few
> errors in webkit_tests and just one error in webkit_gpu_tests.
Do you have a link to that CL?
Are you planning to land that one first?
Or are you saying this is a trybot only error that will not affect the main
waterfall.

[epoger, 2011-11-01 14:34:01]

> Do you have a link to that CL?
> Are you planning to land that one first?
> Or are you saying this is a trybot only error that will not affect the main
> waterfall.

I'm working on that CL right now... turns out it is a WebKit CL (a tiny one). 
It is indeed a trybot-only error that will not affect the main waterfall.

I will add a link to that WebKit CL once I create it.

[reed1, 2011-11-01 14:51:19]

Hard to know anything for sure, since the try-bots don't always reflect the
actual build bots. However given Elliots  analysis and commitment to babysit the
bots afterwards, I think we should try it.

I do see the 001.html/002.html failures in the current bots, so at least on the
CPU side I agree that this won't make anything worse. (btw - we can rebaseline
those after this lands).

LGTM

[epoger, 2011-11-01 15:00:36]

On 2011/11/01 14:34:01, epoger wrote:
> > Do you have a link to that CL?
> > Are you planning to land that one first?
> > Or are you saying this is a trybot only error that will not affect the main
> > waterfall.
> 
> I'm working on that CL right now... turns out it is a WebKit CL (a tiny one). 
> It is indeed a trybot-only error that will not affect the main waterfall.
> 
> I will add a link to that WebKit CL once I create it.

The 3-character WebKit CL is https://bugs.webkit.org/show_bug.cgi?id=71286

[epoger, 2011-11-01 15:17:47]

On 2011/11/01 14:51:19, reed1 wrote:
> Hard to know anything for sure, since the try-bots don't always reflect the
> actual build bots. However given Elliots  analysis and commitment to babysit
the
> bots afterwards, I think we should try it.
> 
> I do see the 001.html/002.html failures in the current bots, so at least on
the
> CPU side I agree that this won't make anything worse. (btw - we can rebaseline
> those after this lands).
> 
> LGTM

Here are the regressions I saw in the trybot (yesterday) for webkit_tests:

Regressions: Unexpected image and text mismatch : (2)
  svg/hixie/perf/001.xml = IMAGE+TEXT
  svg/hixie/perf/002.xml = IMAGE+TEXT

Regressions: Unexpected text diff mismatch : (5)
  fast/dom/nested-script-exceptions.html = TEXT
  fast/js/array-prototype-properties.html = TEXT
  fast/js/exception-sequencing-binops2.html = TEXT
  fast/js/kde/RegExp.html = TEXT
  fast/js/regexp-caching.html = TEXT


Looking at
http://build.chromium.org/p/chromium.webkit/waterfall?show=Webkit%20Mac10.6%2...
, I see that this is the same exact set of failures we were seeing in the
chromium.webkit waterfall at the time:
http://build.chromium.org/p/chromium.webkit/builders/Webkit%20Mac10.6%20%28de...

Still looking at
http://build.chromium.org/p/chromium.webkit/waterfall?show=Webkit%20Mac10.6%2...
, I see that most of these regressions have since been fixed.  Only 001.xml and
002.xml remain.


I am going to add these to test_expectations.txt within this same CL before
submitting.  That should prevent the chromium waterfalls from going red when
this change lands.

[reed1, 2011-11-01 15:25:49]

lgtm