Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Issue 252828 Disable Text Autosizing when viewport width <= device-width and fontScaleFactor <= 100%
Starred by 2 users Project Member Reported by joh...@chromium.org, Jun 21, 2013 Back to list
Status: Fixed
Owner: skobes@chromium.org
Closed: Nov 2013
Cc: kenneth....@intel.com, trchen@chromium.org, klo...@chromium.org, pdr@chromium.org, aelias@chromium.org, timvolod...@chromium.org
Components:
OS: ----
Pri: 2
Type: ----

Blocked on:
issue 135869


Sign in to add a comment
OS: Android
Device: any
Chrome version: all

Currently Chrome for Android will apply a small amount of Text Autosizing even on mobile sites. For a width=device-width page, devices that are up to 320 DIP wide will autosize fonts to 105%, and devices that are 800 DIP wide or greater will autosize fonts to 130%. Devices with widths in between these two values linearly interpolate between 105% and 130%.

(This fudge factor is calculated by the UI layer in http://goto.google.com/gmrnz and gets passed to Blink as part of the textAutosizingFontScaleFactor, multiplied together with the accessibility "text scaling" setting).

This is bad. Using width=device-width (best practice for a mobile site or responsive web design) should mean you get no interference from Text Autosizing. The reason we have it is because tablets often have their devicePixelRatios set too low, and so text is typically less legible on tablets than on phones, and we try to compensate for this (as I was touching on in issue 229151).

We could just remove this fudge factor, but then we'd get slightly unpleasantly small font sizes on tablets. So I think the real solution is to incorporate the fudge factor into the devicePixelRatio using issue 135869 (again, as I was touching on in issue 229151).
 
Comment 1 by skobes@chromium.org, Sep 12, 2013
Owner: skobes@chromium.org
Comment 2 by klo...@chromium.org, Sep 12, 2013
Labels: M-31
This is affecting the performance, especially for the low end devices. Can we make it for M31?
Comment 3 by pdr@chromium.org, Sep 23, 2013
I tested the top 25 sites on both a phone and a tablet and recorded whether we autosized text and what the meta viewport parameters were. The data is available at https://docs.google.com/a/chromium.org/spreadsheet/ccc?key=0Ar5PTHwIpQdLdFBRQkQ3WU54SHJzRDk5dGg1bkd3enc#gid=0

This was collected on live data (not page replays) based on https://en.wikipedia.org/wiki/List_of_most_popular_websites. Where possible, I recorded a second measurement after logging in or searching or visiting a top blog.

Firefox appears to disable text autosizing when the meta viewport tag contains initial-scale or width=device-width.

What do you think about matching Firefox here, and disabling autosizing when these viewport values are present? At least for the top-25, sites that serve these meta parameters to tablets do not end up being autosized so the devicePixelRatio fudge may not be an issue after all.
Comment 4 by pdr@chromium.org, Sep 23, 2013
Cc: pdr@chromium.org
Project Member Comment 5 by bugdroid1@chromium.org, Sep 27, 2013
Labels: -M-31 M-32 MovedFrom-31
Moving all non essential bugs to the next Milestone.
Comment 6 by joh...@chromium.org, Sep 28, 2013
We should disable it whenever the page width in CSS pixels is <= the screen width in DIPs. This corresponds to providing a width=device-width or initial-scale=1 viewport (and various other permutations of viewport properties).

pdr wrote:
> At least for the top-25, sites that serve these meta parameters to tablets do not end up being autosized

What kind of tablet were you using, and in what orientation? When the page has width=device-width and a textAutosizingFontScaleFactor of 1.3, only blocks of text that are more than 76% (1/1.3) of the viewport width will get autosized at all. If you had a large tablet, and especially if you held it in landscape, it's likely that the sites used 2+ column layouts. Maybe 2+ column layouts are common enough that you could indeed disable TA on mobile sites with limited side effects...
Comment 7 by pdr@chromium.org, Sep 28, 2013
@johnme, thank you for taking the time to chat with us about this at BlinkOn. I think we all now agree on the disabling case (when CSS pixels <= screen width in DIPs).

When writing my comment in #3, I did not fully understand that we do need to TA in some cases when CSS pixels > screen width.

I updated the spreadsheet with the orientation information. All the tests were performed on a new Nexus 7 (1920x1200) in vertical orientation. Just from memory, I do not believe any sites were explicitly served as mobile + 2 column. They were primarily either mobile designed (1 column) or the desktop site for tablets.
Comment 8 by pdr@chromium.org, Oct 7, 2013
Status: Assigned
Just to show why this is so important, here's data from google.com (just searched for 'cats') and you can see every layout has a little TextAutosizing component that ends up doing nothing but taking up 1/3 of the layout time for the short layouts.
TextAutosizingTracing.png
624 KB View Download
Comment 9 by pdr@chromium.org, Oct 7, 2013
Cc: trchen@chromium.org
Comment 10 by joh...@chromium.org, Oct 15, 2013
In comment #3, pdr wrote:
> I tested the top 25 sites on both a phone and a tablet and recorded whether we
> autosized text and what the meta viewport parameters were. The data is available at
> https://docs.google.com/a/chromium.org/spreadsheet/ccc?key=0Ar5PTHwIpQdLdFBRQkQ3WU54SHJzRDk5dGg1bkd3enc#gid=0

I notice that of the pages that have mobile viewports, most disallow zooming (with either maximum-scale=1 or user-scalable=no). Disabling zooming should always disable Text Autosizing (even on wide pages), since a core premise of Text Autosizing is that it's not necessary to autosize narrow columns of text since the user can just zoom in on them.

Of the few that have mobile viewports, but don't disallow zooming, we don't autosize google.com results because they explicitly opt out (with the * { max-height: 999999px; } hack), and we don't autosize wikipedia pages because they wrap the page in a height:100% div, which Text Autosizing treats as imposing a height constraint on the page, when really the page was designed to overflow that div all along (this is basically a bug on our part, though tricky to fix).

So there isn't conclusive evidence of whether autosizing is useful or not from those mobile sites (in the interim until the fudge factor is incorporated into issue 135869), but my takeaway is that many mobile sites in practice disable zooming, or otherwise disable autosizing, so we probably wouldn't lose much if we just disabled it for all mobile sites (page width in CSS pixels <= screen width in DIPs), without waiting for the fudge factor to be transferred.

Finally note that alonewithcats.wordpress.com (which doesn't have a mobile viewport) does actually get autosized (from 13px to 16px body font size), and is significantly more legible as a result. Try adjusting Settings > Accessibility > Text Scaling and you'll see the font size change.

In comment #8, pdr wrote:
> Just to show why this is so important, here's data from google.com (just
> searched for 'cats') and you can see every layout has a little TextAutosizing
> component that ends up doing nothing but taking up 1/3 of the layout time for
> the short layouts.

I have a different take-away from that particular trace. It's not the 2nd layouts caused by Text Autosizing that are slowing things down (since there don't seem to be any here, presumably because no new text is being added to the page), it's the actual autosizing tree traversal itself that's taking a significant fraction of layout time in this case (since the layouts are otherwise quick). Could that be becuase Text Autosizing is doing full tree traversals, whereas the rest of layout is happening incrementally? We could probably fix that just by passing in the right subtree to processSubtree?
Comment 11 by pdr@chromium.org, Oct 16, 2013
@johnme,
I agree with your assessment about the mobile sites. We've put together some options in https://docs.google.com/a/chromium.org/document/d/1ZDTJ--IX7qI5QuKMo6aItaZeRuRQajj4GEIB4bCNd-Y/edit, would love your take on them!

For the google.com case, my point was just that we'll be able to remove those text autosizing tree traversals. I don't think it's well known that we're incurring such a cost here. These layouts are likely not subtree layouts but are "full" layouts (caused via JS) with only a few nodes marked as needing layout. Maintaining a list of nodes that need layout prior to the first layout could speed up the text autosizer but the overhead of this could be large.
Comment 12 by nduca@chromium.org, Oct 16, 2013
Labels: Hotlist-Jank
Status: Fixed
With r232248 we no longer autosize pages that specify a meta viewport, unless the user has set the accessibility text scaling slider to > 100%.
Correction: with r232248, pages that specify a meta viewport no longer have an automatic 1.05-1.3x boost (the "device scale adjustment") applied to the font scale factor.  Autosizing is still possible if the meta viewport sets a layout width > device width.
Blocking: chromium:324779
Sign in to add a comment