Using attached screenshot as reference, 1 is Tree style tabs, 2 is the black background caused. The black area appears to change depending on how big the side bar area use is. Using something like bookmarks sidebar also increases the black area. To reproduce the black area completely I need to change tabs from then to the gmail one. I'm happy to debug further if needed. Its been happening for a while now, just have not had time to report. Since this doesn't happen on other installations of mine which all use TST I'm adding some stuff from the troubleshooting page. Name Firefox Version 36.0a1 User Agent Mozilla/5.0 (Windows NT 6.3; WOW64; rv:36.0) Gecko/20100101 Firefox/36.0 Multiprocess Windows 0/2 Adapter Description AMD Radeon HD 7700 Series Adapter Drivers aticfx64 aticfx64 aticfx64 aticfx32 aticfx32 aticfx32 atiumd64 atidxx64 atidxx64 atiumdag atidxx32 atidxx32 atiumdva atiumd6a atitmm64 Adapter RAM 1024 Device ID 0x683d Direct2D Enabled true DirectWrite Enabled true (6.3.9600.17111) Driver Date 9-15-2014 Driver Version 14.301.1001.0 GPU #2 Active false GPU Accelerated Windows 2/2 Direct3D 11 (OMTC) Subsys ID 201c1787 Vendor ID 0x1002 WebGL Renderer Google Inc. -- ANGLE (AMD Radeon HD 7700 Series Direct3D9Ex vs_3_0 ps_3_0) windowLayerManagerRemote true AzureCanvasBackend direct2d AzureContentBackend direct2d 1.1 AzureFallbackCanvasBackend cairo AzureSkiaAccelerated 0

Just tried in a brand new profile with just the bookmarks sidebar open and was able to reproduce it with back relative to size of sidebar.

This happens in non-nightly channel as well?

I know it was happening early this month so I know its reached Aurora. Will have to check Beta and Release though.

Yeah, the problem is in Aurora 35.0a2 (2014-10-21) but not Beta 34.0.

I was finally able to locate where the background image was attached in Gmail so then I was able to make a test case. This testcase has exactly the same problem as the Gmail page.

Great, thanks for the reduced test case! I see this on Windows 7, Quadro 600. Setting gfx.direct2d.disabled to true makes the problem go away, as does turning off OMTC.

This just started happening on another computer that I use nightly on (maybe because this one updates rarely). This time its a 16:9 screen and the cutoff is at the bottom. Same testcase still applies.

This is due to Direct2D 1.1, we're getting really complicated transforms and sampling bounds here to render this image. This is a little odd since we shouldn't really need that here, I'll fix this bug but we might want to look into whether we -want- to use SamplingBounds at all in this case, it seems fairly wasteful.

[Tracking Requested - why for this release]:

Fixes it for me.

I actually still wanted this info from Matt, and this was a great example of a reproducible case, I could raise a separate bug but I'm hoping Matt will be able to tell me if there's any value in that or whether this is just a special case.

Quite probably not :) It's the image code that decides if we need sampling restriction or not, but generally if the html has specified only part of an image to be visible then we'll add sampling restrictions in case they are use a sprite sheet.

(In reply to Matt Woodrow (:mattwoodrow) from comment #19) > Quite probably not :) > > It's the image code that decides if we need sampling restriction or not, but > generally if the html has specified only part of an image to be visible then > we'll add sampling restrictions in case they are use a sprite sheet. In this case there seems to be absolutely no reason for that. The image is fullscreen, no sampling artifacts would ever negatively effect the image we project. And it's causing a relatively high cost, once the image is 'optimized'.

(In reply to Bas Schouten (:bas.schouten) from comment #20) > In this case there seems to be absolutely no reason for that. The image is > fullscreen, no sampling artifacts would ever negatively effect the image we > project. And it's causing a relatively high cost, once the image is > 'optimized'. Can you explain that some more? What I see from the gmail screenshot vs the actual image is that we're cutting off the left edge of the image. That combined with a transform would mean that we're resampling, and we might sample from some pixels to the left of what we expect to be visible. Obviously that doesn't matter at all for this particular choice of image, but it could for some images.

I guess the occlusion on the left edge is not because of how the image was asked to be drawn, but instead because of some other content sitting on top of it. If that's the only reason that we're using sampling restriction, then maybe we could fix that.

:bas Could you uplift tha patch to Aurora35.0a2? (the patch fixed Bug 1077071, Bug 1080431, Bug 1081337 Bug, 1081384)

(In reply to Alice0775 White from comment #23) > :bas > Could you uplift tha patch to Aurora35.0a2? > (the patch fixed Bug 1077071, Bug 1080431, Bug 1081337 Bug, 1081384) I'll create a patch to disable D2D 1.1 on Aurora. There's more bugs and we shouldn't be rushing to address them all on Aurora I think :-).

(In reply to Bas Schouten (:bas.schouten) from comment #24) > (In reply to Alice0775 White from comment #23) > > :bas > > Could you uplift tha patch to Aurora35.0a2? > > (the patch fixed Bug 1077071, Bug 1080431, Bug 1081337 Bug, 1081384) > > I'll create a patch to disable D2D 1.1 on Aurora. There's more bugs and we > shouldn't be rushing to address them all on Aurora I think :-). Okay, I understand.

no longer tracking for 35 since d2d 1.1 was disabled there.