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)

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

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

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

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.

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?

it is grayscale AA

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

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

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.

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.

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

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.