1085187 - Gmail background cut off due to side bars

Status: RESOLVED FIXED

(Core :: Graphics, defect)

Description

[Hugh Nougher [:Hughman]]

Attachment: Gmail Screenshot

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

Comment 1

[Hugh Nougher [:Hughman]]

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.

Comment 2

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

This happens in non-nightly channel as well?

Comment 3

[Hugh Nougher [:Hughman]]

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

Comment 4

[Hugh Nougher [:Hughman]]

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

Comment 5

[Hugh Nougher [:Hughman]]

Attachment: Reduced Testcase

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.

Comment 6

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

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.

Comment 7

[Hugh Nougher [:Hughman]]

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.

Comment 9

[Bas Schouten (:bas.schouten)]

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.

Comment 10

[Bas Schouten (:bas.schouten)]

Attachment: Properly restrict the uploaded area in DrawTargetD2D1::CreateBrushForPattern

Comment 14

[Bas Schouten (:bas.schouten)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/0c50940fd16d

Comment 15

[Alice0775 White]

[Tracking Requested - why for this release]:

Comment 16

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/0c50940fd16d

Comment 17

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

Fixes it for me.

Comment 18

[Bas Schouten (:bas.schouten)]

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.

Comment 19

[Matt Woodrow (:mattwoodrow)]

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.

Comment 20

[Bas Schouten (:bas.schouten)]

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

Comment 21

[Matt Woodrow (:mattwoodrow)]

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

Comment 22

[Matt Woodrow (:mattwoodrow)]

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.

Comment 23

[Alice0775 White]

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

Comment 24

[Bas Schouten (:bas.schouten)]

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

Comment 25

[Alice0775 White]

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

Comment 26

[Lukas Blakk [:lsblakk] use ?needinfo]

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