1158575 - Content does not get subpixel AA with e10s when unaccelerated

Status: RESOLVED FIXED

(Core :: Graphics: Text, defect)

Description

[Mayank Bansal]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.0
Build ID: 20150425030208

Steps to reproduce:

1. Create a new profile
2. Go to http://www.virsanghvi.com/Article-Details.aspx?key=451


Actual results:

The fonts dont look right. 
Chrome and IE11 look better


Expected results:

not so.

Comment 1

[Alice0775 White]

Could you paste "Graphic Section" of about:support (Alt > Help > Troubleshooting Information)

Comment 2

[Mayank Bansal]

Attachment: about support.txt

Adapter Description: Intel(R) G41 Express Chipset
Adapter Drivers: igdumd64 igd10umd64 igdumdx32 igd10umd32
Adapter RAM: Unknown
Asynchronous Pan/Zoom: none
Device ID: 0x2e32
DirectWrite Enabled: false (6.2.9200.16492)
Driver Date: 10-4-2012
Driver Version: 8.15.10.2869
GPU #2 Active: false
GPU Accelerated Windows: 1/1 Direct3D 11 WARP (OMTC)
Subsys ID: 75921462
Vendor ID: 0x8086
WebGL Renderer: Google Inc. -- ANGLE (Intel(R) G41 Express Chipset Direct3D9Ex vs_3_0 ps_3_0)
windowLayerManagerRemote: true
AzureCanvasBackend: skia
AzureContentBackend: cairo
AzureFallbackCanvasBackend: cairo
AzureSkiaAccelerated: 0

Comment 3

[Alice0775 White]

I can reproduce the poor font rendering with e10s:on HWA:off.
Font is Gray-scale AA instead of sub-pixel AA.

Comment 4

[Jim Mathies [:jimm]]

Milan, we think this is a dupe of another warp bug, any ideas?

Comment 5

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

Is this a dupe of 1155228?

Comment 6

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

(In reply to George Wright (:gw280) from comment #5)
> Is this a dupe of 1155228?

Hard to tell without the image of what the problem looked like, but probably.

Comment 7

[Alice0775 White]

I can reproduce the problem with e10s:on HWA:off on old Nightly (at least 2014-12-01). 
So, I think this is similar, but not a same.

Comment 8

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

Can you provide a screenshot of what you're seeing?

Comment 9

[Alice0775 White]

Attachment: screenshot x400%

it is grayscale AA

Comment 10

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

(In reply to Alice0775 White from comment #9)
> Created attachment 8598993 [details]
> screenshot x400%
> 
> it is grayscale AA

Agreed, don't think this is bug 1155228.  I'm assuming the reporter's problem is the same as the attached image. I can't quite recall, but I think we do have some limitations on subpixel AA, right Bas?

Comment 11

[Bas Schouten (:bas.schouten)]

(In reply to Jim Mathies [:jimm] from comment #4)
> Milan, we think this is a dupe of another warp bug, any ideas?

I'm waiting for a build to test this, but this should render identically with WARP or D3D11 without OMTC. There's shouldn't be a reason for it being different. But perhaps there's a bug somewhere.

(In reply to Milan Sreckovic [:milan] from comment #10)
> (In reply to Alice0775 White from comment #9)
> > Created attachment 8598993 [details]
> > screenshot x400%
> > 
> > it is grayscale AA
> 
> Agreed, don't think this is bug 1155228.  I'm assuming the reporter's
> problem is the same as the attached image. I can't quite recall, but I think
> we do have some limitations on subpixel AA, right Bas?

This is indeed not bug 1155228. Bug 1155228 was a problem when someone was -not- getting warp for a window, in this case the user is getting WARP for that window. But somehow still no subpixel AA.

Comment 12

[Bas Schouten (:bas.schouten)]

Attachment: Screenshot D3D11/Cairo

Something very peculiar is going on here, this is the text with D3D11 and non-warp. it's subpixel anti-aliased, but it's terrible in a uniquely different way.

Comment 13

[Bas Schouten (:bas.schouten)]

With Basic OMTC or D3D11 WARP for me the page is rendered looking absolutely terrible as well but both with subpixel AA. E10S does not seem to work under a debugger at the moment, or at least I can't seem to get the plugin-container process to stay up long enough to attach a debugger.

Comment 14

[Bas Schouten (:bas.schouten)]

I've confirmed with E10S we lose subpixel AA here.

In short:

This font always looks pretty terrible.
It looks more terrible when not using D2D.
When using E10S -and- not using D2D it seems to lose subpixel AA.

Let's use this bug to fix the grayscale issue, which indeed does seem to be e10s specific. I suspect this is a graphics issue with the type of texturehost/client pair we use. I'll have a look at this.

Comment 15

[Bas Schouten (:bas.schouten)]

Basically we never create a DIBTextureClient when using e10s. So essentially right now we never get subpixel AA on content when e10s is on.

Comment 16

[Bas Schouten (:bas.schouten)]

Morphing as agreed.

Comment 17

[Bas Schouten (:bas.schouten)]

Attachment: Support using GDI rendering for opaque surfaces when using cross process layers

Comment 18

[Bas Schouten (:bas.schouten)]

Attachment: Support using GDI rendering for opaque surfaces when using cross process layers v2

Restructured a little to be cleaner and have more code reuse.

Comment 19

[Jeff Muizelaar [:jrmuizel]]

Comment on attachment 8605737 [details] [diff] [review]
Support using GDI rendering for opaque surfaces when using cross process layers v2

Review of attachment 8605737 [details] [diff] [review]:
-----------------------------------------------------------------

::: gfx/layers/client/TextureClient.cpp
@@ +368,4 @@
>    }
> +  if (!texture && aFormat == SurfaceFormat::B8G8R8X8 &&
> +      !aAllocator->IsSameProcess() &&
> +      aMoz2DBackend == gfx::BackendType::CAIRO) {

having an if (isSameProcess()) { } else {} inside would be cleaner than duplicating the other conditions.

Comment 20

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/651158be720b

Comment 21

[Phil Ringnalda (:philor)]

https://hg.mozilla.org/mozilla-central/rev/651158be720b