Revert 46492 to repair perf regression in XP single-core Moz Page Cycler

Actually, this only reverts the windows specific portion of 46492.

Initial revert and restore (see revisions 52456 and 52441) 
seemed to show that this was indeed the cause of the regression.  
There was some problem with the perf bot, so I'm landing again
to confirm that this removes the regression.

As pointed out by pkasting, this is all browser side
computation, but on a single core (as noted by Darin),
browser processing becomes critical path (and can impact perf).
My suspicioun is that the original code did some caching of its
font metrics, and this was not (to the same extent??) being
done in the replacement (centralized) code.

If this does not provide the perf fix I'm expecting, I'll revert it.


BUG=47227
TBR=pkasting
Review URL: http://codereview.chromium.org/3023002

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@52599 0039d316-1c4b-4281-b951-d872f2087c98

1 files changed, 2 insertions, 4 deletions

diff --git a/views/controls/label.cc b/views/controls/label.cc
index e2f5091..a9448ba7 100644
--- a/views/controls/label.cc
+++ b/views/controls/label.cc
@@ -365,10 +365,8 @@ gfx::Rect Label::GetTextBounds() const {
     case ALIGN_LEFT:
       break;
     case ALIGN_CENTER:
-      // We put any extra margin pixel on the left rather than the right.  We
-      // used to do this because measurement on Windows used
-      // GetTextExtentPoint32(), which could report a value one too large on the
-      // right; we now use DrawText(), and who knows if it can also do this.
+      // We put any extra margin pixel on the left rather than the right since
+      // GetTextExtentPoint32() can report a value one too large on the right.
       text_origin.Offset((available_rect.width() + 1 - text_size.width()) / 2,
                          0);
       break;