New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 21 users

Issue metadata

Status: Verified
Email to this user bounced
Closed: Nov 2013
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 2
Type: Bug-Regression

Sign in to add a comment

Issue 285066: Jaggy text on

Reported by, Sep 4 2013 Project Member

Issue description

Application Version (from "Chrome Settings > About Chrome"): 30.0.1599.29 & 31.0.1621.0
Android Build Number (from "Android Settings > About Phone/Tablet"): JWR66Y
Device: Nexus 4

Steps to reproduce: 
1. Go to

Observed behavior: 
'4Viewers' heading & navbar text is jaggy (screenshots to follow)

Expected behavior: 
Text to be rendered correctly


Additional comments: 
Works as expected in M29

Comment 1 by, Sep 4 2013

Comment 2 by, Sep 4 2013

Similar jagginess observed on Screenshots added to http://go/chrome-androidlogs/285066/

Comment 3 by, Sep 4 2013

Status: Available

Comment 4 by, Sep 4 2013

I suspect this is the result of disabling canvas AA as it did in

We need to figure out our choice.

Comment 5 by, Sep 4 2013

Labels: -Restrict-View-Google Hotlist-ConOps
Opening up so we can collect external feedback on this as well. 

Jason - can we also see if anyone is reporting jaggy text on some parts of the page on M30 Beta.

Comment 6 by, Sep 4 2013

FYI, the affected text should be drawn inside the <canvas>.

Comment 7 by, Sep 5 2013

There have not been reports of this from Beta users via Report an Issue or in the Chrome Forum. I can reproduce it using the links in comments #0 and #2.

Comment 8 by, Sep 12 2013

Labels: -M-30 -ReleaseBlock-Stable M-31

Comment 9 by, Sep 12 2013

Both Channel 4 & Inventist appear to be using Cufón ( Further examples @

Also affects sites that use typeface.js (

Comment 10 by, Oct 4 2013

Labels: Cr-Internals-GPU

Comment 11 by, Oct 7 2013

Is there something we should be doing here? Maybe wait until we can enable MSAA for canvas?

Comment 12 by, Oct 7 2013

Labels: -Cr-Internals-GPU Cr-Internals-GPU-Canvas2D Cr-Blink-Canvas
I think we decided to leave AA off in M31, is that right Grace?

Meanwhile Brian and Sami were looking at enabling MSAA on tiled GPUs that should make it cheap enough to do.

Out of curiosity, how does this look in other browsers (e.g. Firefox on Android or iOS Safari)?

Comment 13 Deleted

Comment 14 by, Oct 8 2013

Screenshots of in Firefox for Android & Mobile Safari added to http://go/chrome-androidlogs/285066/ - both of which look considerably better than it does in M30.

Comment 15 by, Oct 8 2013

Our choices are either re-enable custom AA or enable MSAA. This feels like a product manager decision to me. We do have some improvements coming for cases where we fall back to SW (less CPU time, smaller upload).

Comment 16 by, Oct 8 2013

Can we check Dolphin on a JB mr2 device?

If MSAA is cheap and fast, we can start to turn it on when it is available. Brian?

Comment 17 by, Oct 8 2013

It looks better in Dolphin (10.1.0) than it does in M30 too - screenshot added to http://go/chrome-androidlogs/285066/

Device: Nexus 4

Comment 18 by, Oct 8 2013

Is it with jetpack? According to #4, they do not anti alias path neither.

Comment 19 by, Oct 9 2013

It looks the same in Dolphin both with & without Jetpack enabled.

Comment 20 by, Oct 9 2013

Perhaps they've enabled MSAA.

Grace, I believe it is fast and cheap on Mali devices. It *should* be fast and cheap on IMG devices and is in standalone Skia but is very slow when Skia uses it in Chrome. This needs to be diagnosed. Adreno will require exposing ES3 MSAA to Skia via cmd buffer. Note that even on earlier versions of Android (pre K-K) the Andreno driver supports ES3/MSAA and it could be exposed to Skia.

I'm working on adding a flag to enable MSAA (when it is available).

Comment 21 by, Oct 9 2013

Labels: -M-31 M-32
Can QA redo the test mentioned in #4?

Brian, let us turn on AA whenever MSAA is available. M31 seems aggressive, m32 sounds reasonable?

Comment 22 by, Oct 9 2013


Comment 23 by, Oct 9 2013

We could use help from someone on GPU infra. on exposing GL_EXT_framebuffer_multisample/GL_EXT_framebuffer_blit via the command buffer on Android for devices that support ES3 MSAA.

Comment 24 by, Oct 10 2013

Sami, can you help to plumb it through? Thanks.

Comment 25 by, Oct 14 2013

Labels: ReleaseBlock-Stable

Comment 26 by, Oct 15 2013

 Issue 306288  has been merged into this issue.

Comment 27 by, Oct 23 2013

It appears that AA for *all* vector rendering has been turned off on Chrome for Android. Is that correct? It's devastating to an application we recently launched where we render text ourselves with vector commands on canvas.

Comment 28 by, Oct 23 2013

Mo, Brandon, does either of you have cycles to add support for GL_EXT_framebuffer_multisample to the cmd-buffer as per Brian's comment #23?

Comment 29 by, Oct 24 2013

DevRel has been hearing from an increasing number of our top partners on this issue.

I was hoping to see the change was made based on developer performance reports, but unfortunately I'm not seeing that. 

Reading the issue history it appears we regressed the visual fidelity purely for benchmark performance.

Do we have any regression tests that could have caught this?

I've attached some of the screenshots of this issue.
91.9 KB View Download
110 KB View Download
183 KB View Download[slash]rtor_Dolphin-vs-m30.png
588 KB View Download

Comment 30 by, Oct 24 2013

Since we render text onto canvases using regular vector commands, our text is basically illegible at most normal sizes now.

We recently launched Lucidpress as a way to publish rich digital content online, particularly for tablets. Our content looked great during development on Android tablets, but now we have recently launched and our published content looks terrible on Android tablets.

For example, here is a simple mostly-text page. Try opening this on an Android device with the current version of Chrome:

We're all confused about how this happened. Everything seemed to work quite well and with decent performance in the previous version of Chrome on Android.

Comment 32 by, Oct 24 2013

Thanks Oliver. Can you also test M29 for the comparison?

Comment 33 by, Oct 24 2013

Status: Assigned

Comment 34 by, Oct 24 2013

I want to be clear that turning on MSAA for *all* devices won't happen in M32. In fact some devices don't support MSAA at all. For those cases someone (PM?) needs to make a judgement call whether to revert to the older M29 non-MSAA-but-AA-enabled code path or stick with the current M30/M31 no-AA code path.

Comment 36 by, Oct 24 2013

 Issue 310459  has been merged into this issue.

Comment 37 by, Oct 27 2013

#34 does that mean no antialiasing in M32 for 2012 Nexus 7 (Tegra 3) devices?

Comment 38 by, Oct 29 2013

Project Member
r231615 | | 2013-10-29T19:33:43.090014Z

Changed paths:

Add a basic test for GL_CHROMIUM_framebuffer_multisample

BUG= 285066 

Review URL:

Comment 39 by, Nov 6 2013

Our app draws data viz charts on canvases.  It's lost AA on Nexus 7 both 2012 and 2013 and looks terrible.  Chrome 30 Android.

Comment 40 by, Nov 11 2013

 Issue 317175  has been merged into this issue.

Comment 41 by, Nov 12 2013

 Issue 317664  has been merged into this issue.

Comment 42 by, Nov 12 2013

Ok. We will turn back the software AA when MSAA is not available.

Brian, can you remove the flag in android/ to re-enable software aa path? And make sure we will use hw AA when it is available. Thanks.

Comment 43 Deleted

Comment 44 by, Nov 13 2013

You guys should track back how you made this decision to disable AA in the first place because it made all canvas-based web apps and games look like crap on low and mid-range devices.
I hope disabled AA didn't make it into android 4.4 chromium-powered webkit.

Comment 45 by, Nov 13 2013

Grace, where should the change be made? Trunk and cherry-pick to M32?

Comment 46 by, Nov 14 2013


Comment 47 by, Nov 15 2013

The flag change will be for M32..

Comment 48 by, Nov 19 2013

Project Member
r236024 | | 2013-11-19T19:04:26.633397Z

Changed paths:

Android: Reenable canvas anti-aliasing

This reverts r213238 (and r227928 which moved things around).

Choose quality ( ) over benchmark scores
The long-term solution for both is hw msaa ( ).

BUG= 285066 ,164719

Review URL:

Comment 49 by, Nov 19 2013

Labels: Merge-Requested
Requesting merge for r236024 since it's a simple cmdline flag revert.

Comment 50 by, Nov 19 2013

Labels: Hotlist-DevRel

Comment 51 by, Nov 19 2013

Labels: -Merge-Requested Merge-Approved

Comment 52 by, Nov 19 2013

Project Member
Labels: -Merge-Approved merge-merged-1700
r236067 | | 2013-11-19T23:23:39.894759Z

Changed paths:

Merge 236024 "Android: Reenable canvas anti-aliasing"

> Android: Reenable canvas anti-aliasing
> This reverts r213238 (and r227928 which moved things around).
> Choose quality ( ) over benchmark scores
> (
> The long-term solution for both is hw msaa ( ).
> BUG= 285066 ,164719
> NOTRY=True
> Review URL:

Review URL:

Comment 53 by, Nov 20 2013

Status: Verified
----Verification Attempt----
App Version: 32.0.1700.22
Device Make/Model/Revision: Nexus 4, Nexus 5, Nexus 7 (2013), Nexus 7 (2012), Nexus 10, Nexus S, Galaxy Nexus, HTC One, Samsung Galaxy S3
Test Case Name That Will Catch Regression: TBD

Steps Performed To Verify Fix:

As per #1, #2, #9, #29, #30,  issue 306288 ,  issue 310459 ,  issue 317175  &  issue 317664  

Verification Succeeded (yes/no): Yes

Comment 54 by, Nov 27 2013

Chrome 32.0.1700.23 Intel Z2560 Clovertrail+ 1.6GHz x86/PowerVR SGX 544MP2@400 = 6.61FPS = 16.0FPS = 4.42FPS

Chrome is just unusable.

Sign in to add a comment