Closed Bug 1322169 Opened 3 years ago Closed 3 years ago

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

Categories

(Core :: Canvas: WebGL, defect, P3, major)

50 Branch
x86_64
Windows 10
defect

Tracking

()

RESOLVED DUPLICATE of bug 1330672
mozilla52
Tracking Status
firefox50 --- wontfix
firefox51 --- fixed
firefox52 --- fixed
firefox53 --- fixed

People

(Reporter: balev, Assigned: kvark)

References

Details

(Keywords: regression, Whiteboard: [gfx-noted])

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.
Severity: normal → major
OS: Unspecified → Windows 10
Hardware: Unspecified → x86_64
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)
Component: Untriaged → Canvas: WebGL
Product: Firefox → Core
A testcase to narrow down a regression range in FF50 would be very useful.
Flags: needinfo?(balev)
Keywords: testcase-wanted
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.
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.
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)
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.
Depends on: 1286348
Priority: -- → P3
Whiteboard: [gfx-noted]
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.
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.
Flags: needinfo?(jgilbert)
This is great - thank you!

It looks like 51 will be released late January next year - is that correct?
(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.
(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
Status: UNCONFIRMED → RESOLVED
Closed: 3 years ago
Flags: needinfo?(jgilbert) → needinfo?(milan)
Resolution: --- → FIXED
Flags: needinfo?(milan)
Flags: needinfo?(balev)
Assignee: nobody → jwwang
Blocks: 1286348
Depends on: 1311872
No longer depends on: 1286348
Target Milestone: --- → mozilla52
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?
Please retest.
Flags: needinfo?(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.
We can reproduce this on one of our computers.
Dzmitry, can you update here the status on nightly vs. stable?
Status: RESOLVED → REOPENED
Ever confirmed: true
Flags: needinfo?(kvark)
Resolution: FIXED → ---
Assignee: jwwang → kvark
Bug 1330672 comment 21 correlates this to pixi.js, which is also used in spark.adobe.com.
Status: REOPENED → RESOLVED
Closed: 3 years ago3 years ago
Flags: needinfo?(kvark)
Flags: needinfo?(balev)
Resolution: --- → DUPLICATE
Duplicate of bug: 1330672
You need to log in before you can comment on or make changes to this bug.