1322169 - Sometimes video textures in WebGL are upside-down. Windows only, V50 injection

Status: RESOLVED DUPLICATE of bug 1330672

(Core :: Graphics: CanvasWebGL, defect, P3)

Description

[Dimcho Balev]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.98 Safari/537.36

Steps to reproduce:

We are shipping new feature for our web app (https://spark.adobe.com/) that is using video elements as a sources to WebGL textures.

After upgrading firefox to v50.0.2 we started seeing occasionally (<100%) upside-down video textures. This is an injection in v50 since v49 on the same machine doesn't exhibit the problem. It is also windows only problem, as FFv50 on Mac is fine. We  tried on several machines with different hardware configurations (Intel, nVidia GPUs) and the results are identical so this doesn't seem to be an video driver related.

We can provide an access to our beta program where the issues can reproduced pretty easily.


Actual results:

Upside down video textures


Expected results:

Normally oriented video textures as they are rendered in Edge, Safari, Chrome and old versions of Firefox.

Comment 1

[Dimcho Balev]

Some additional clarifications: 
- We are using pixi.js v4 in our rendering engine
- The bug is unpredictable. The upside down is not happening for every video texture. If this was the case it would be possible to have at least temporary workaround (for example check the user agent string and flip the textures only for the FFv50 clients)
- The issue is happening when we have multiple video elements and after we add few more (everything is fine with just one or two video elements)

Comment 2

[Loic]

A testcase to narrow down a regression range in FF50 would be very useful.

Comment 3

[Dimcho Balev]

Unfortunately we can't provide a simple test case at the moment as we haven't narrowed down yet the exact condition that is triggering the bug. As I mentioned earlier we can give you access to our beta program of the app where we can reliably reproduce it.

Comment 4

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

Can you run the mozregression tool in your app and send us the results.  That would be as good as a test case to start.
It is possible it was an ANGLE update in bug 1281687.

Comment 5

[Dimcho Balev]

Very useful tool - I really like it!

This is the final output:

2016-12-09T15:57:11: DEBUG : Using url: https://hg.mozilla.org/integration/mozilla-inbound/json-pushes?changeset=b15f05a94c716fdbed45b5f46a0fd5b8ae6443ef&full=1
2016-12-09T15:57:12: DEBUG : Found commit message:
Bug 1286348 - Only set ROW_LENGTH if it's different. - r=mtseng

MozReview-Commit-ID: 6Wl9iKeYudg


It seems that the fix for https://bugzilla.mozilla.org/show_bug.cgi?id=1286348 caused the regression:
"Reintroduce support for UNPACK_FLIP_Y and UNPACK_PREMULTIPLY_ALPHA for WebGL2"

The good news is that the bug is NO LONGER present in the latest build I tried: Nightly 53.0.a1(2016-12-06)

Comment 6

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

Thanks for going to the trouble of finding this!

Given that this is fixed, it'd be interesting to find out what actually fixed it; there is a way to ask mozregression to do the "when was this problem fixed" type of search.  If we knew what fixed it, we could (hopefully) uplift the fix to beta and aurora, instead of leaving people with the problem for a few months while the version with the fix goes through the release trains.

Comment 7

[Dimcho Balev]

Running mozzregression with "search for bug fix" yielded this:

2016-12-12T16:19:08: DEBUG : Using url: https://hg.mozilla.org/integration/autoland/json-pushes?changeset=6efd141313d472eda740931b77a2167f7eae2b4b&full=1
2016-12-12T16:19:08: DEBUG : Found commit message:
Bug 1311872. Part 5 - disable dormant when running mochitests. r=cpearce,jya

MozReview-Commit-ID: ETFdW7V707j

I don't think commit ETFdW7V707j fixed it, since it is just a change in the tests, but the bug itself: https://bugzilla.mozilla.org/show_bug.cgi?id=1311872 looks related to our issue (we do load several video elements in memory and keep them paused).

I also had to retest 2 builds during the bisection process since I saw flipped texture briefly, but after I tested them for 2nd time the texture orientation stayed stable.

Let me know if this is pointing in the right direction and what else I can do on my end to help.

Comment 8

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

We are planning on uplifting most of the WebGL related things from 53 to 51, so we just have to make sure it includes the fix.

Comment 9

[Dimcho Balev]

This is great - thank you!

It looks like 51 will be released late January next year - is that correct?

Comment 10

[Loic]

(In reply to Dimcho Balev from comment #9)
> This is great - thank you!
> 
> It looks like 51 will be released late January next year - is that correct?

See https://wiki.mozilla.org/RapidRelease/Calendar for release dates.

Comment 11

[Kelsey Gilbert [:jgilbert]]

(In reply to Dimcho Balev from comment #5)
> Very useful tool - I really like it!
> 
> This is the final output:
> 
> 2016-12-09T15:57:11: DEBUG : Using url:
> https://hg.mozilla.org/integration/mozilla-inbound/json-
> pushes?changeset=b15f05a94c716fdbed45b5f46a0fd5b8ae6443ef&full=1
> 2016-12-09T15:57:12: DEBUG : Found commit message:
> Bug 1286348 - Only set ROW_LENGTH if it's different. - r=mtseng
> 
> MozReview-Commit-ID: 6Wl9iKeYudg
> 
> 
> It seems that the fix for
> https://bugzilla.mozilla.org/show_bug.cgi?id=1286348 caused the regression:
> "Reintroduce support for UNPACK_FLIP_Y and UNPACK_PREMULTIPLY_ALPHA for
> WebGL2"
> 
> The good news is that the bug is NO LONGER present in the latest build I
> tried: Nightly 53.0.a1(2016-12-06)

Marking this as fixed for 51 and 52.

I think this is wontfix for 50? :milan

Comment 12

[Dimcho Balev]

I think the bug was present in 51 and 52 when I tested them. 53 was fine. 

Are you guys planning on porting this particular change back to 51 and this is why you are marking the bug as fixed in 51 and 52?

Comment 13

[Kelsey Gilbert [:jgilbert]]

Please retest.

Comment 14

[Dimcho Balev]

I just retested: the bug is happening both in 52.0a2 and 51.0b11.

So unless some WebGL changes from 53 are ported back to 51 as Milan suggested the bug will be still there.

Our video feature is already out officially and the bug could be tested live here:

https://spark.adobe.com/

You can create free account to start using the product. In order to reproduce the bug you need to create project with 3 or more slides and import mpeg videos in each. Usually the bug is immediately visible or it will appear as soon as you stat rearranging the order of the slides.

Comment 15

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

We can reproduce this on one of our computers.
Dzmitry, can you update here the status on nightly vs. stable?

Comment 16

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

Bug 1330672 comment 21 correlates this to pixi.js, which is also used in spark.adobe.com.