1294213 - NPNVsupportsAsyncWindowsDXGISurfaceBool in Nightly 51.0a1 doesn't match Firefox 48.0

Status: RESOLVED DUPLICATE of bug 1292498

(Core Graveyard :: Plug-ins, defect)

Description

[mtalistu]

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

Steps to reproduce:

In a recent Nightly 51.0a1 build (08-08-2016), it seems that NPN_GetValue() for NPNVsupportsAsyncWindowsDXGISurfaceBool is always returning false, even though the Release Firefox 48.0 returns true on the same machine.

This prevents wmode=direct content from being windowless when Async Drawing is enabled, and we fall back to the previous windowed wmode=direct implementation, which I understand can be problematic with e10s enabled.


Actual results:

Load wmode=direct SWF content. Flash Player plugin sends NPN_GetValue() message for NPNVsupportsAsyncWindowsDXGISurfaceBool to see if hardware support is available. Nightly 51.0a1 returns false, and Firefox 48.0 returns true.


Expected results:

Both browsers should return true.

Comment 1

[Benjamin Smedberg]

As with bug 1290528, this is probably e10s-related. If you disable e10s, does this work properly?

Code path in question:
http://searchfox.org/mozilla-central/source/dom/plugins/ipc/PluginInstanceChild.cpp#473
http://searchfox.org/mozilla-central/source/dom/plugins/ipc/PluginInstanceParent.cpp#391 -> #375
http://searchfox.org/mozilla-central/source/gfx/thebes/gfxWindowsPlatform.cpp#2075

I can easily imagine we're asking the wrong process those questions, or a similar bug.

Is there an testcase that would make it easy to test this in various configs and confirm visually whether we're getting the asyncdrawing or windowed solution?

Comment 2

[Benjamin Smedberg]

I tried this on x86-64 nightly and NPNVsupportsAsyncWindowsDXGISurfaceBool appears to be reporting true. Is this x86-specific?

Comment 3

[mtalistu]

If I disable e10s, I see the same results in 32-bit Nightly (no Async Hardware support indicated)

If I run the x64 Nightly, the behavior matches release 48.0, and hardware support comes back true. It is true whether or not e10s is enabled.

I disabled our Protected Mode sandbox in the 32-bit Nightly as a sanity check for the 32-bit Nightly, and that didn't make a difference. 32-bit still returned false when Protected Mode was disabled.

I will see if I can get a simple test case together that makes it obvious whether Direct mode is using the windowless vs windowed solution.

Comment 4

[mtalistu]

Attachment: test case to display async hardware support

This test case will display the Context3D driver info string. On Win 7, if Async Drawing is hardware accelerated, this will be DirectX11. If we fall back to the normal windowed wmode=direct implementation because the browser indicates it doesn't support hardware async drawing, this will be DirectX9.

Comment 5

[Benjamin Smedberg]

I cannot reproduce this even on x86. On win7 running a 32-bit nightly, I run the testcase and it reports directx11 (and I can confirm using spy++ that we're running a windowless Flash instance).

mtalistu, can you attach your about:support data for the x86 Firefox where this fails?

Comment 6

[mtalistu]

Attachment: about:support for Nightly 51.0a1 x86 (failure case)

Comment 7

[mtalistu]

Attachment: about:support for Nightly 51.0a1 x64 (success case)

Comment 8

[mtalistu]

Attachment: about:support for Firefox 48.0 x86 (success case)

Comment 9

[mtalistu]

Here are three about:support reports from my Lenovo w520 laptop running Win7. The Firefox 48.0 and Nightly x64 are passing cases, and the Nightly x86 is the failing case.

Note that another dev here is seeing similar results on his Dell desktop. Will ask for about:supports from that machine as well.

Comment 10

[Jim Mathies [:jimm]]

tracy, please test to see if you can reproduce.

Comment 11

[Jim Mathies [:jimm]]

I'm not seeing this. I get

"On win 7, will be DX11 if Async Hardware is supported, DX9 or software otherwise. driver: directx11"

Windows 7
Nightly 51.0a1 (2016-08-14) x86 
Flash: Version: 23.0.0.134

Comment 12

[Benjamin Smedberg]

On x86, we appear to be using D3D9. On x86-64, we're using D3D11. And:
DIRECT2D:
failed by runtime: Direct3D11 device does not support texture sharing

Bas or Matt, can you explain the discrepancy in D3D version support between x86 and x86-64 in this case?

Comment 13

[Tracy Walker [:tracy]]

Attachment: about:support Win7 x86

With on Win 7 (x86, VM) with latest Nightly 51.0a1, 20160815030201, with e10s on (or off) I get:

"On win 7, will be DX11 if Async Hardware is supported, DX9 or software otherwise. driver: directx9"

Comment 14

[Matt Woodrow (:mattwoodrow)]

This looks like bug 1292498, is it fixed again in the latest Nightly?

Comment 15

[Jim Mathies [:jimm]]

(In reply to Tracy Walker [:tracy] from comment #13)
> Created attachment 8781252 [details]
> about:support Win7 x86
> 
> With on Win 7 (x86, VM) with latest Nightly 51.0a1, 20160815030201, with
> e10s on (or off) I get:
> 
> "On win 7, will be DX11 if Async Hardware is supported, DX9 or software
> otherwise. driver: directx9"

Looks like this is due to the use of the vm.

Comment 16

[Jim Mathies [:jimm]]

(In reply to mtalistu from comment #0)
> In a recent Nightly 51.0a1 build (08-08-2016), it seems that NPN_GetValue()
> for NPNVsupportsAsyncWindowsDXGISurfaceBool is always returning false, even
> though the Release Firefox 48.0 returns true on the same machine.

A patch landed on 8-9 that should've address this. Would you mind updating and retesting? We're seeing the proper output from your test case in the latest nightly builds.

Comment 17

[mtalistu]

After updating to the x86 Nightly 51.0a1 (2016-08-16), I see DirectX11 support again for Async Drawing, so it appears to be fixed. Thanks!

Comment 18

[Jim Mathies [:jimm]]

Thanks!