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, 12 insertions, 3 deletions

diff --git a/gfx/font_win.cc b/gfx/font_win.cc
index f9b7243..5660cc7 100644
--- a/gfx/font_win.cc
+++ b/gfx/font_win.cc
@@ -170,9 +170,18 @@ Font Font::DeriveFont(int size_delta, int style) const {
 }
 
 int Font::GetStringWidth(const std::wstring& text) const {
-  int width = 0, height = 0;
-  CanvasSkia::SizeStringInt(text, *this, &width, &height,
-                            gfx::Canvas::NO_ELLIPSIS);
+  int width = 0;
+  HDC dc = GetDC(NULL);
+  HFONT previous_font = static_cast<HFONT>(SelectObject(dc, hfont()));
+  SIZE size;
+  if (GetTextExtentPoint32(dc, text.c_str(), static_cast<int>(text.size()),
+                           &size)) {
+    width = size.cx;
+  } else {
+    width = 0;
+  }
+  SelectObject(dc, previous_font);
+  ReleaseDC(NULL, dc);
   return width;
 }