Closed Bug 1158575 Opened 5 years ago Closed 5 years ago

Content does not get subpixel AA with e10s when unaccelerated

Categories

(Core :: Graphics: Text, defect)

defect
Not set

Tracking

()

RESOLVED FIXED
mozilla41
Tracking Status
e10s m8+ ---
firefox41 --- fixed

People

(Reporter: mayankleoboy1, Assigned: bas.schouten)

Details

Attachments

(4 files, 1 obsolete file)

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.
Could you paste "Graphic Section" of about:support (Alt > Help > Troubleshooting Information)
Flags: needinfo?(mayankleoboy1)
Attached file 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
Flags: needinfo?(mayankleoboy1)
I can reproduce the poor font rendering with e10s:on HWA:off.
Font is Gray-scale AA instead of sub-pixel AA.
Status: UNCONFIRMED → NEW
tracking-e10s: --- → ?
Component: Layout: Text → Graphics: Text
Ever confirmed: true
Milan, we think this is a dupe of another warp bug, any ideas?
Flags: needinfo?(milan)
Is this a dupe of 1155228?
(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.
Flags: needinfo?(milan)
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.
Can you provide a screenshot of what you're seeing?
Flags: needinfo?(mayankleoboy1)
Attached image screenshot x400%
it is grayscale AA
Flags: needinfo?(mayankleoboy1)
(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?
Flags: needinfo?(bas)
(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.
Flags: needinfo?(bas)
Attached image 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.
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.
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.
Assignee: nobody → bas
Basically we never create a DIBTextureClient when using e10s. So essentially right now we never get subpixel AA on content when e10s is on.
Morphing as agreed.
Summary: Font does not look right on http://www.virsanghvi.com/Article-Details.aspx?key=451 → Content does not get subpixel AA with e10s when unaccelerated
Restructured a little to be cleaner and have more code reuse.
Attachment #8605681 - Attachment is obsolete: true
Attachment #8605681 - Flags: review?(jmuizelaar)
Attachment #8605737 - Flags: review?(jmuizelaar)
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.
Attachment #8605737 - Flags: review?(jmuizelaar) → review+
https://hg.mozilla.org/mozilla-central/rev/651158be720b
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla41
You need to log in before you can comment on or make changes to this bug.