User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:41.0) Gecko/20100101 Firefox/41.0 Build ID: 20150604030205 Steps to reproduce: 1. create a new profile 2. Go to http://genius.com/5140245 3. Notice the font of the main lyrics 4. Notice the font of the explanatory text on right Actual results: looks sort of fuzzy/difficult to read Expected results: clearer. Compare it with the rendering on chrome.

tried with e10s on/off and HWA on/off

I can reproduce on Emulated Blocked GPU. user_pref("gfx.direct2d.disabled", true); user_pref("layers.acceleration.force-enabled", true); user_pref("layers.offmainthreadcomposition.enabled", true); Graphics -------- Adapter Description: AMD Radeon HD 6450 Adapter Drivers: aticfx64 aticfx64 aticfx64 aticfx32 aticfx32 aticfx32 atiumd64 atidxx64 atidxx64 atiumdag atidxx32 atidxx32 atiumdva atiumd6a atitmm64 Adapter RAM: 1024 Asynchronous Pan/Zoom: none ClearType Parameters: Gamma: 2200 Pixel Structure: R ClearType Level: 100 Enhanced Contrast: 200 Device ID: 0x6779 DirectWrite Enabled: false (6.2.9200.17292) Driver Date: 11-20-2014 Driver Version: 14.501.1003.0 GPU #2 Active: false GPU Accelerated Windows: 1/1 Direct3D 11 (OMTC) Subsys ID: 23111787 Supports Hardware H264 Decoding: true Vendor ID: 0x1002 WebGL Renderer: Google Inc. -- ANGLE (AMD Radeon HD 6450 Direct3D9Ex vs_3_0 ps_3_0) windowLayerManagerRemote: true AzureCanvasBackend: skia AzureContentBackend: cairo AzureFallbackCanvasBackend: cairo AzureSkiaAccelerated: 0 And also I can reproduce on Disabled HWA Graphics -------- Adapter Description: AMD Radeon HD 6450 Adapter Drivers: aticfx64 aticfx64 aticfx64 aticfx32 aticfx32 aticfx32 atiumd64 atidxx64 atidxx64 atiumdag atidxx32 atidxx32 atiumdva atiumd6a atitmm64 Adapter RAM: 1024 Asynchronous Pan/Zoom: none ClearType Parameters: Gamma: 2200 Pixel Structure: R ClearType Level: 100 Enhanced Contrast: 200 Device ID: 0x6779 DirectWrite Enabled: false (6.2.9200.17292) Driver Date: 11-20-2014 Driver Version: 14.501.1003.0 GPU #2 Active: false GPU Accelerated Windows: 0/1 Basic (OMTC) Subsys ID: 23111787 Supports Hardware H264 Decoding: false Vendor ID: 0x1002 WebGL Renderer: Google Inc. -- ANGLE (AMD Radeon HD 6450 Direct3D11 vs_5_0 ps_5_0) windowLayerManagerRemote: true AzureCanvasBackend: skia AzureContentBackend: cairo AzureFallbackCanvasBackend: cairo AzureSkiaAccelerated: 0 But, I cannot reproduce enabled HWA Graphics -------- Adapter Description: AMD Radeon HD 6450 Adapter Drivers: aticfx64 aticfx64 aticfx64 aticfx32 aticfx32 aticfx32 atiumd64 atidxx64 atidxx64 atiumdag atidxx32 atidxx32 atiumdva atiumd6a atitmm64 Adapter RAM: 1024 Asynchronous Pan/Zoom: none ClearType Parameters: Gamma: 2200 Pixel Structure: R ClearType Level: 100 Enhanced Contrast: 200 Device ID: 0x6779 Direct2D Enabled: true DirectWrite Enabled: true (6.2.9200.17292) Driver Date: 11-20-2014 Driver Version: 14.501.1003.0 GPU #2 Active: false GPU Accelerated Windows: 1/1 Direct3D 11 (OMTC) Subsys ID: 23111787 Supports Hardware H264 Decoding: true Vendor ID: 0x1002 WebGL Renderer: Google Inc. -- ANGLE (AMD Radeon HD 6450 Direct3D11 vs_5_0 ps_5_0) windowLayerManagerRemote: true AzureCanvasBackend: direct2d 1.1 AzureContentBackend: direct2d 1.1 AzureFallbackCanvasBackend: cairo AzureSkiaAccelerated: 0

Disabled e10s seems to fix the problem for me with HWA off

I think this is not a regression. This is a E10s implementation bug.

reproduced with HWA off and e10s on not reproduced with HWA off and e10s off

Jonathan, any ideas here?

The screenshot (attachment 8622784 [details]) shows that with e10s on, we're not getting subpixel antialiasing; this is particularly noticeable with the light-on-dark text. This is an issue for someone like Bas, I'd guess.

Possibly related to bug 1158575?

(In reply to George Wright (:gw280) from comment #9) > Possibly related to bug 1158575? I think the fix to bug 1158575 will have fixed this.

The build that the reporter is using should have the fix from bug 1158575, so I don't think so?

Bas, can you reproduce this with a build before bug 1158575 landed and confirm that its fixed after it landed?

Looks like I screwed up a last minute change processing a review comment for bug 1158575. Testing the fix now.

Backed out in https://hg.mozilla.org/integration/mozilla-inbound/rev/026e77985e59

We have the code in a bad state right now, so we should try to fix it or remove/comment/whatever the code that is not quite right before we forget about it. I can reproduce the problem that got this backed out, with e10s and no acceleration on my Windows 7 machine. I hit an assert of "boxShadowDT->GetType() not equal to aDT.GetType()" inside of gfxBlur.cpp, Bas is that any hint of what code is missing/making wrong assumptions now that we added shmem DIM client?

Before the above assert happens, we call Factory::CreateDrawTargetForData with BackendType::DIRECT2D1_1. That seems wrong on a few levels (recall that we're running with acceleration off.) Stack looks something like: Factory::CreateDrawTargetForData ImageDataSerializeBase::GetAsDrawTarget BufferTextureClient::BorrowDrawTarget ContentClientRemoveBuffer::CreateBuffer ... which means ContentClientRemoteBuffer::CreateBackBuffer creates the wrong client?

(In reply to Milan Sreckovic [:milan] from comment #20) > Before the above assert happens, we call Factory::CreateDrawTargetForData > with BackendType::DIRECT2D1_1. That seems wrong on a few levels (recall > that we're running with acceleration off.) > Stack looks something like: > Factory::CreateDrawTargetForData > ImageDataSerializeBase::GetAsDrawTarget > BufferTextureClient::BorrowDrawTarget > ContentClientRemoveBuffer::CreateBuffer > ... > which means ContentClientRemoteBuffer::CreateBackBuffer creates the wrong > client? Yes, that is very bad. Looking through the code it's not immediately obvious to be how that would happen.

Some notes. We get into TextureClient::CreateForDrawing with aMoz2DBackend set to BackendType::NONE. We happily then assign it the result of GetContentBackend(), which is set to DIRECT2D1_1. In the meantime, the parentBackend, obtained from GetCompositorBackendType() is LAYERS_BASIC. As all other options fail, we call CreateBufferTextureClient with aMoz2DBackend set to DIRECT2D1_1, which creates MemoryTextureClient with the same backend flag, at which point it's an accident waiting to happen - and it does in the situation described in comment 21. TextureClient::CreateForDrawing is called by ContentClientRemoveBuffer::CreateBackBuffer, and NONE is the type we always pass in. By the time we call gfxPlatform::GetContentBackend(), we have already initialized it to mRenderMode RENDER_DIRECT2D and mContentBackend DIRECT2D1_1. During that initialization, we call gfxPlatform::InitBackendPrefs. Inside of it we call GetContentBackendPref, which returns CAIRO. So far, so good. In the gfxWindowsPlatform constructor, we test if Direct2DUse1_1 preference is set, and if it is, we call InitD3D11Devices. That seems wrong. We have layers.acceleration.disabled set, chances are we should not be calling InitD3D11Devices.

After the stuff above, the constructor calls UpdateRenderMode, which again calls InitBackendPrefs, and this time through decides that, DIRECT2D1_1, rather than CAIRO is the way to go. And then bad things happen.

renom because an m8+ bug was duped to this

Bas, are you working on this? Got an ETA?

I have Bas buried in startup crashes work, so probably not :)

This is the same as bug 1072501. I commented there, the only real thing we can do here is enable it again, see the crashes come back, and hope we end up being able to get in touch with someone who can reproduce them. In other words any ETA would be pure guesswork.

per comment 28, can we dupe this over to bug 1072501 and track on that?

Sure.

Somebody can move tracking-e10s: m8+ to bug 1072501