Make the LCD text device scale factor threshold 1.5 inclusive

Make the LCD text device scale factor threshold 1.5 inclusive

Currently, compositing will be preferred to LCD text on all Android
devices as well as on other platforms when the device scale factor is
strictly greater than 1.5. As the 1.5 cutoff was somewhat arbitrary, and
many popular tablets have a scale factor of 1.5, switch that threshold
to be 1.5 inclusive. This improves scroll performance on such devices,
where smooth touchscreen or touchpad scrolling is a likely scenario.

BUG=517188
Committed: https://crrev.com/7d452b4a6ad1028f03a82cc7e43ff6024445c75b
Cr-Commit-Position: refs/heads/master@{#344317}

[jdduke (slow), 2015-08-18 18:33:02]

jdduke@chromium.org changed reviewers:
+ jschuh@chromium.org, scottmg@chromium.org, vollick@chromium.org

[jdduke (slow), 2015-08-18 18:33:03]

Comments? Concerns? I've been looking for a regular monitor that defaults to a
1.5 scale factor but I can't seem to find one.

[Ian Vollick, 2015-08-18 18:34:17]

On 2015/08/18 18:33:03, jdduke wrote:
> Comments? Concerns? I've been looking for a regular monitor that defaults to a
> 1.5 scale factor but I can't seem to find one.

Sure, non owner lg2m.

[scottmg, 2015-08-18 19:11:37]

On 2015/08/18 18:33:03, jdduke wrote:
> Comments? Concerns? I've been looking for a regular monitor that defaults to a
> 1.5 scale factor but I can't seem to find one.

On a Surface Pro 3 at 150% we're not using LCD decimation in the content area
anyway. https://code.google.com/p/chromium/issues/detail?id=517188#c26

Are we sure this actually does anything? Is there something else that's turning
off a fast scrolling path?

(I have a http://www.samsung.com/us/computer/monitors/LU28D590DS/ZA which
defaults to 150 but am not in front of it until next week)

[jdduke (slow), 2015-08-18 21:04:20]

On 2015/08/18 19:11:37, scottmg wrote:
> On 2015/08/18 18:33:03, jdduke wrote:
> > Comments? Concerns? I've been looking for a regular monitor that defaults to
a
> > 1.5 scale factor but I can't seem to find one.
> 
> On a Surface Pro 3 at 150% we're not using LCD decimation in the content area
> anyway. https://code.google.com/p/chromium/issues/detail?id=517188#c26
> 
> Are we sure this actually does anything? Is there something else that's
turning
> off a fast scrolling path?
> 
> (I have a http://www.samsung.com/us/computer/monitors/LU28D590DS/ZA which
> defaults to 150 but am not in front of it until next week)

At the least, this change kicks us into the fast path for pages with background
images (as with http://www.tagesschau.de/, if you show repaints in devtools
we're always repainting otherwise with the Surface). There may be other
scenarios where the |settings.preferCompositingToLCDTextEnabled()| signal comes
into play.

[scottmg, 2015-08-18 21:18:18]

On 2015/08/18 21:04:20, jdduke wrote:
> On 2015/08/18 19:11:37, scottmg wrote:
> > On 2015/08/18 18:33:03, jdduke wrote:
> > > Comments? Concerns? I've been looking for a regular monitor that defaults
to
> a
> > > 1.5 scale factor but I can't seem to find one.
> > 
> > On a Surface Pro 3 at 150% we're not using LCD decimation in the content
area
> > anyway. https://code.google.com/p/chromium/issues/detail?id=517188#c26
> > 
> > Are we sure this actually does anything? Is there something else that's
> turning
> > off a fast scrolling path?
> > 
> > (I have a http://www.samsung.com/us/computer/monitors/LU28D590DS/ZA which
> > defaults to 150 but am not in front of it until next week)
> 
> At the least, this change kicks us into the fast path for pages with
background
> images (as with http://www.tagesschau.de/, if you show repaints in devtools
> we're always repainting otherwise with the Surface). There may be other
> scenarios where the |settings.preferCompositingToLCDTextEnabled()| signal
comes
> into play.

OK, I confirm that I see that here too (avoiding paint on scroll). Annoying that
we don't actually _get_ LCD text on this device as is, but that's not exactly
the same as this issue, so lgtm. (I'm not owner though)

[jdduke (slow), 2015-08-18 21:29:12]

jdduke@chromium.org changed reviewers:
+ sievers@chromium.org

[jdduke (slow), 2015-08-18 21:29:13]

+sievers for owner review.

https://codereview.chromium.org/1293083003/diff/1/content/renderer/render_vie...
File content/renderer/render_view_impl.cc (right):

https://codereview.chromium.org/1293083003/diff/1/content/renderer/render_vie...
content/renderer/render_view_impl.cc:366: return device_scale_factor >= 1.5f;
I'm assuming we don't do any funky math when piping down that scale factor that
might yield something 1.4999 or such... I suspect we'd have bigger issues
if/when that is the case.

[no sievers, 2015-08-18 22:44:47]

lgtm

[jdduke (slow), 2015-08-19 19:32:23]

The CQ bit was checked by jdduke@chromium.org

[jdduke (slow), 2015-08-19 19:32:23]

The patchset sent to the CQ was uploaded after l-g-t-m from
sievers@chromium.org, scottmg@chromium.org
Link to the patchset: https://codereview.chromium.org/1293083003/#ps20001
(title: "Rebase")

[commit-bot: I haz the power, 2015-08-19 19:33:20]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1293083003/20001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1293083003/20001

[commit-bot: I haz the power, 2015-08-19 21:25:28]

Committed patchset #2 (id:20001)

[commit-bot: I haz the power, 2015-08-19 21:26:22]

Patchset 2 (id:??) landed as
https://crrev.com/7d452b4a6ad1028f03a82cc7e43ff6024445c75b
Cr-Commit-Position: refs/heads/master@{#344317}