Fix for the WebInputEventBuilderTest.TestMouseEventScale content_unittests failures on the DrMemory…

Fix for the WebInputEventBuilderTest.TestMouseEventScale content_unittests failures on the DrMemory Windows builder.

The test attempts to force a device scale factor via the force-device-scale-factor command line switch. While this works
well in isolation, the test would fail if another test before it forces the device scale factor to something else.

Reason being the device scale factor code uses static variables to determine if the scale factor has been forced and
caches the value. This is done as an optimization as there are lots of calls to the GetDPIScale and related functions.

Fix is to get rid of the static variables used to track if we checked for a forced device scale factor and the forced
scale factor value. These are now global variables which can be reset via a static function
Display::ResetForceDeviceScaleFactor.

The WebInputEventBuilderTest.TestMouseEventScale test calls the above function to reset the forced device scale factor
state.

BUG=411634
TBR=cpu

Committed: https://crrev.com/449c2485458f40a9627a9f2517c6297bd180aa80
Cr-Commit-Position: refs/heads/master@{#320049}

[ananta, 2015-03-10 22:09:11]

ananta@chromium.org changed reviewers:
+ scottmg@chromium.org

[scottmg, 2015-03-10 23:02:01]

https://codereview.chromium.org/992383002/diff/20001/ui/gfx/display.cc
File ui/gfx/display.cc (right):

https://codereview.chromium.org/992383002/diff/20001/ui/gfx/display.cc#newcode57
ui/gfx/display.cc:57: if (g_ForcedDeviceScaleFactor < 0)
I think it would be less complex to have 

  bool g_have_computed_scale_factor = false;

And then have the reset function set that back to false, rather than overloading
the values themselves.

https://codereview.chromium.org/992383002/diff/20001/ui/gfx/display.h
File ui/gfx/display.h (right):

https://codereview.chromium.org/992383002/diff/20001/ui/gfx/display.h#newcode57
ui/gfx/display.h:57: static void ResetForceDeviceScaleFactor();
I think this should have a "ForTesting" suffix.

[ananta, 2015-03-10 23:31:57]

https://codereview.chromium.org/992383002/diff/20001/ui/gfx/display.cc
File ui/gfx/display.cc (right):

https://codereview.chromium.org/992383002/diff/20001/ui/gfx/display.cc#newcode57
ui/gfx/display.cc:57: if (g_ForcedDeviceScaleFactor < 0)
On 2015/03/10 23:02:01, scottmg wrote:
> I think it would be less complex to have 
> 
>   bool g_have_computed_scale_factor = false;
> 
> And then have the reset function set that back to false, rather than
overloading
> the values themselves.

Sadly that would be tricky. Given that we have two static values which need to
be invalidated on one flag. Leaving this as is and renamed the global variables
as per discussion.

https://codereview.chromium.org/992383002/diff/20001/ui/gfx/display.h
File ui/gfx/display.h (right):

https://codereview.chromium.org/992383002/diff/20001/ui/gfx/display.h#newcode57
ui/gfx/display.h:57: static void ResetForceDeviceScaleFactor();
On 2015/03/10 23:02:01, scottmg wrote:
> I think this should have a "ForTesting" suffix.

Done.

[scottmg, 2015-03-10 23:39:44]

lgtm

[ananta, 2015-03-10 23:43:26]

ananta@chromium.org changed reviewers:
+ sky@chromium.org

[ananta, 2015-03-10 23:43:49]

+sky for ui owners.

[sky, 2015-03-11 00:03:41]

https://codereview.chromium.org/992383002/diff/40001/ui/gfx/display.cc
File ui/gfx/display.cc (left):

https://codereview.chromium.org/992383002/diff/40001/ui/gfx/display.cc#oldcode47
ui/gfx/display.cc:47: static const float kForcedDeviceScaleFactor =
UGH! Can we always look at the command line switch and avoid all this nonsense?

[ananta, 2015-03-11 00:06:52]

https://codereview.chromium.org/992383002/diff/40001/ui/gfx/display.cc
File ui/gfx/display.cc (left):

https://codereview.chromium.org/992383002/diff/40001/ui/gfx/display.cc#oldcode47
ui/gfx/display.cc:47: static const float kForcedDeviceScaleFactor =
On 2015/03/11 00:03:41, sky wrote:
> UGH! Can we always look at the command line switch and avoid all this
nonsense?

That would be great. Would this heavy traffic code path result in performance
issues caused by reading the command line each time?

[sky, 2015-03-11 03:52:21]

*SIGH* No doubt you're right. LGTM

[ananta, 2015-03-11 04:18:50]

The CQ bit was checked by ananta@chromium.org

[ananta, 2015-03-11 04:18:50]

The patchset sent to the CQ was uploaded after l-g-t-m from scottmg@chromium.org
Link to the patchset: https://codereview.chromium.org/992383002/#ps60001 (title:
"Fixed boneheaded error")

[commit-bot: I haz the power, 2015-03-11 04:19:02]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/992383002/60001

[commit-bot: I haz the power, 2015-03-11 04:37:16]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-03-11 04:37:17]

Try jobs failed on following builders:
  chromium_presubmit on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)

[ananta, 2015-03-11 04:47:41]

ananta@chromium.org changed reviewers:
+ cpu@chromium.org

[ananta, 2015-03-11 04:47:42]

+cpu. Tbring

[ananta, 2015-03-11 04:48:36]

The CQ bit was checked by ananta@chromium.org

[commit-bot: I haz the power, 2015-03-11 04:48:43]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/992383002/60001

[commit-bot: I haz the power, 2015-03-11 05:02:21]

Committed patchset #4 (id:60001)

[commit-bot: I haz the power, 2015-03-11 05:02:57]

Patchset 4 (id:??) landed as
https://crrev.com/449c2485458f40a9627a9f2517c6297bd180aa80
Cr-Commit-Position: refs/heads/master@{#320049}