995129 - After gradient stops at y=32768 layer pixels, solid background changed from white to black

Status: RESOLVED DUPLICATE of bug 671302

(Core :: Graphics, defect)

Description

[wbsecg1]

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.116 Safari/537.36

Steps to reproduce:

aurora(30) or nightly(31) view  http://demos.jquerymobile.com/1.2.1/docs/api/events.html 

scroll and scroll


Actual results:

background is black under half of the page


Expected results:

background should be white

Comment 1

[Aaron Train [:aaronmt]]

I can reproduce this on my Nexus 5 (4.4.2). Scrolling down the page quickly and all of a sudden the tiles are turned black.

See attached screenshot in next comment.

Comment 2

[Aaron Train [:aaronmt]]

Attachment: screenshot.png

Comment 3

[wbsecg1]

also in b2g

Comment 4

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

Yup, I'm tracking the meta bug 996062.

Comment 5

[Jason Smith [:jsmith]]

Can we check if this happens on the latest 1.4 build on a production device?

Comment 6

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

I believe this is Fennec only, we don't have low res tiling enabled on B2G, but I imagine it's worth a B2G test anyway.

Comment 7

[J Zimbrick]

I have not been able to reproduce this issue on the latest Buri 1.4 Aurora build.
Attempted to reproduce the five times and did not see this reproduce.

The background remained white while scrolling the entire time.

Environmental Variables:
Device: Buri
BuildID: 20140417000204
Gaia: 00a9d55a3e7463cecfb5dde185c0ee1f4c4d9e54
Gecko: d3d40652aaa2
Version: 30.0a2
Base Image: V1.2-device.cfg

Comment 8

[Kartikaya Gupta (email:[e-mail])]

Turns out this has nothing to do with tiling or low-res stuff, or even panning. The background is just black after y=16384.

Adding regressionwindow-wanted because I don't think this is caused by tiling changes. Assuming it is a recent regression we should be able to find a culprit change with a straightforward bisection.

Comment 9

[u421692]

Good build:2014-03-08
Bad build: 2014-03-09

Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=d01bf8596d3b&tochange=21f293fc8d34

Comment 10

[u421692]

I'm guessing maybe it's a regression from Bug 963073 - (b2g-tiling) Turn on tiled scrollable layers on b2g ?

Comment 11

[Kartikaya Gupta (email:[e-mail])]

Thanks. I did local builds to bisect that range further and it's cset 8394fed3332e from bug 963073.

Comment 12

[Kartikaya Gupta (email:[e-mail])]

Looking at the layer dump when this happens, I see the ThebesLayerComposite has a shadow-transform at -32768. I strongly suspect that this is the same issue as bug 671302 but my Nexus 4 is painting the page at a 2.0 resolution and so I see the background disappear at 16384 instead.

I don't know why the tiling changes exposed this bug when it wasn't manifesting before.

Comment 13

[Kartikaya Gupta (email:[e-mail])]

Note that per bug 671302 comment 34 this used to affect Fennec before too. So maybe the question is when it got fixed and why it came back.

Comment 14

[Nicolas Silva [:nical]]

32768 is 1 more than what a 16bits signed integer can carry, so we should look at what in our code and in the drawing libraries we use (especially cairo) might be using 16bits integers for positions, transformations, etc.

Comment 15

[Kartikaya Gupta (email:[e-mail])]

Ok, tn pointed me to http://hg.mozilla.org/mozilla-central/rev/b82ef4adc4d8 which fixed the timecube issue. This issue is slightly different in that it deals with a background color rather than a background image, and so would need an analogous fix somewhere.

Comment 16

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Does or would Skia have this same problem?

Comment 17

[Kartikaya Gupta (email:[e-mail])]

Hopefully not, but until we actually isolate the problem I can't say for sure.

Comment 18

[Kartikaya Gupta (email:[e-mail])]

So, it turns out that the jquerymobile page is using a gradient for a background, which makes this bug a straight-up dupe of bug 671302. Also of note is that this bug *does* exist on current release Fennec, but there, at y=32768 layer pixels, the background gradient stops and is replaced by a solid *white* background. (This is barely noticeable because of the light-colored gradient but if you look closely you can see it). After bug 963072 landed, the solid white background got replaced by a solid black background. I'm not sure why that happened and frankly I'm not sure it really matters. The real problem is that the background stops at all.

I'm going to close this as a dupe but if we really care about getting the white background back instead of the black background then we can reopen it.

Also note that the background at y>32768 is not necessarily always black now. For instance, the simplified test case I constructed at http://people.mozilla.org/~kgupta/bug/995129.html shows a white background after the gradient is truncated on both Fennec release and Nightly.