diff options
| author | asvitkine@chromium.org <asvitkine@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2011-10-27 21:21:11 +0000 |
|---|---|---|
| committer | asvitkine@chromium.org <asvitkine@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2011-10-27 21:21:11 +0000 |
| commit | dc309f0e7faa2b8e0a4558edf4976a23ba100cc7 (patch) | |
| tree | 17b6d7a02d15e4b118f5a2238d831a87a68fad77 /chrome | |
| parent | d3765982212c3cfc9bf56f5c853edfdb051735b0 (diff) | |
| download | chromium_src-dc309f0e7faa2b8e0a4558edf4976a23ba100cc7.zip chromium_src-dc309f0e7faa2b8e0a4558edf4976a23ba100cc7.tar.gz chromium_src-dc309f0e7faa2b8e0a4558edf4976a23ba100cc7.tar.bz2 | |
Correct text y position calculation in RenderTextWin.
The previous calculation had a problem due to the following logic:
SkPoint point(SkPoint::Make(SkIntToScalar(offset.x()),
SkIntToScalar(display_rect().height() - offset.y())));
If display_rect().y() was large and height was the height for e.g. one line of text, then when the code subtracted offset.y() (which was based on display_rect().y()), the result was a negative y position (offscreen) for the text.
This CL changes the logic to correctly center the text vertically regardless of the y position, which I believe was the intention of the code.
BUG=none
TEST=Open Chrome with --use-pure-views. Type something into omnibox. Text should be centered in omnibox.
Review URL: http://codereview.chromium.org/8401032
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@107625 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'chrome')
0 files changed, 0 insertions, 0 deletions