1172014 - [e10s] font subpixel anti-aliasing disabled when e10s enabled

Status: RESOLVED DUPLICATE of bug 1072501

(Core :: Graphics: Layers, defect)

Description

[Mayank Bansal]

Attachment: bug.png

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.

Comment 1

[Mayank Bansal]

Attachment: about support.txt

tried with e10s on/off and HWA on/off

Comment 2

[Alice0775 White]

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

Comment 3

[Alice0775 White]

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

Comment 4

[Alice0775 White]

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

Comment 5

[Alice0775 White]

Attachment: testcase

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

Comment 6

[Alice0775 White]

Attachment: screenshot

Comment 7

[George Wright (:gw280) (needinfo me!)]

Jonathan, any ideas here?

Comment 8

[Jonathan Kew [:jfkthame]]

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.

Comment 9

[George Wright (:gw280) (needinfo me!)]

Possibly related to bug 1158575?

Comment 10

[Bas Schouten (:bas.schouten)]

(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.

Comment 11

[George Wright (:gw280) (needinfo me!)]

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

Comment 12

[Brad Lassey [:blassey] (use needinfo?)]

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

Comment 13

[Bas Schouten (:bas.schouten)]

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

Comment 14

[Bas Schouten (:bas.schouten)]

Attachment: Correctly use TextureClientShmemDIB

Comment 15

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/54d4d88b2f2f

Comment 16

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/54d4d88b2f2f

Comment 17

[Jeff Muizelaar [:jrmuizel]]

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

Comment 19

[Milan Sreckovic [:milan] (needinfo for best results)]

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?

Comment 20

[Milan Sreckovic [:milan] (needinfo for best results)]

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?

Comment 21

[Bas Schouten (:bas.schouten)]

(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.

Comment 22

[Milan Sreckovic [:milan] (needinfo for best results)]

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.

Comment 23

[Milan Sreckovic [:milan] (needinfo for best results)]

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.

Comment 25

[Brad Lassey [:blassey] (use needinfo?)]

renom because an m8+ bug was duped to this

Comment 26

[Brad Lassey [:blassey] (use needinfo?)]

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

Comment 27

[Milan Sreckovic [:milan] (needinfo for best results)]

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

Comment 28

[Bas Schouten (:bas.schouten)]

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.

Comment 30

[Jim Mathies [:jimm]]

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

Comment 31

[Milan Sreckovic [:milan] (needinfo for best results)]

Sure.

Comment 32

[Milan Sreckovic [:milan] (needinfo for best results)]

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