712868 - tilt does not honour webgl.force-enabled preference

Status: VERIFIED FIXED

(DevTools :: Inspector, defect)

Description

[Mike Beltzner [:beltzner, not reading bugmail]]

My 2011-12-21 nightly under Windows 7 doesn't have a 3D button in the inspector. No old demoware addons hanging around, prefs and about:support all looks clean, and yet this is what I see when I try to rock the Inspector: 

http://i.imgur.com/CPCUx.png

about:config prefs are set to:
 devtools.tilt.enabled true
 devtools.tilt.force-enabled false

Comment 1

[Mike Beltzner [:beltzner, not reading bugmail]]

Gavin suggested flipping force-enabled to true - doing that and restarted showed the 3D button, and then tilt worked:

http://i.imgur.com/OFgLO.png

So the codepath is there, but for some reason we're not detecting that WebGL is available. This is strange because WebGL Google Maps works just fine, as do other WebGL sites and demos.

Comment 2

[Rob Campbell [:rc] (:robcee)]

for whatever reason the graphics probe we're using for the 3D button doesn't seem to be working, despite WebGL clearly-being available on your machine. I wonder if that hardware's blacklisted for some reason?

cc'ing victor for a consult.

Comment 3

[Victor Porof [:vporof][:vp]]

The most likely reason is that the drivers/hardware are blacklisted. CC'ing bjacob, as he suggested that we test for FEATURE_NO_INFO using nsIGfxInfo.
Thee are the snippets that tests if the 3D button should be enabled:

https://hg.mozilla.org/mozilla-central/rev/cb4feeed6ac5#l9.1567

and

https://hg.mozilla.org/mozilla-central/rev/cb4feeed6ac5#l8.274

Comment 4

[Mike Beltzner [:beltzner, not reading bugmail]]

It's a SONY VAIO Z, which I believe Asa and Mossop also have.

Driver info from about:support

Adapter Description  NVIDIA GeForce GT 330M
Vendor ID            0x10de
Device ID            0x0a2b
Adapter RAM          1024
Adapter Drivers      nvd3dumx,nvwgf2umx,nvwgf2umx nvd3dum,nvwgf2um,nvwgf2um
Driver Version       8.16.11.9024
Driver Date          6-4-2010
Direct2D Enabled     true
DirectWrite Enabled  true (6.1.7601.17563)
ClearType Parameters Gamma: 2200 Pixel Structure: RGB ClearType Level: 100 Enhanced Contrast: 50 
WebGL Renderer       Google Inc. -- ANGLE (NVIDIA GeForce GT 330M) -- OpenGL ES 2.0 (ANGLE 1.0.0.924)
GPU Accelerated Windows 2/2 Direct3D 10
AzureBackend         direct2d

Comment 5

[Dave Townsend [:mossop]]

(In reply to Mike Beltzner [:beltzner] from comment #4)
> It's a SONY VAIO Z, which I believe Asa and Mossop also have.

So I do not have force-enabled on and Tilt sometimes works for me. I haven't yet verified this but my suspicion is that if I have my laptop connected to its docking station (which includes an external GPU) when I start Firefox, and I then disconnect the dock without restarting then webgl is broken. After restarting Firefox it starts working again. The same may be true of the reverse. Unfortunately my dock is in the office where I will not be for a while to verify this.

Comment 6

[Mike Beltzner [:beltzner, not reading bugmail]]

Hm, I leave my computer on "Speed" mode all the time, but I suspect it's something to do with the multiple graphics cards thing, yeah.

What's odd, though, is that web content still detects that I'm WebGL capable (as per http://get.webgl.org/ and the like) but for some reason this code thinks it is not!

Comment 7

[Dave Townsend [:mossop]]

(In reply to Mike Beltzner [:beltzner] from comment #6)
> Hm, I leave my computer on "Speed" mode all the time, but I suspect it's
> something to do with the multiple graphics cards thing, yeah.
> 
> What's odd, though, is that web content still detects that I'm WebGL capable
> (as per http://get.webgl.org/ and the like) but for some reason this code
> thinks it is not!

Ah the problem I was seeing was that even webgl wouldn't work, get.webgl.org said something like my browser claimed to support it but it couldn't initialise it so maybe my drivers were outdated. Then after a restart all fine.

Comment 8

[Victor Porof [:vporof][:vp]]

(In reply to Dave Townsend (:Mossop) from comment #7)
> Ah the problem I was seeing was that even webgl wouldn't work, get.webgl.org
> said something like my browser claimed to support it but it couldn't
> initialise it so maybe my drivers were outdated. Then after a restart all
> fine.

As this seems not directly related to Tilt, but other issues regarding WebGL drivers or support for multiple gfx cards, maybe we can WORKSFORME this bug?

Comment 9

[Mike Beltzner [:beltzner, not reading bugmail]]

How on earth is this WORKSFORME?

I filed a bug because Tilt will not function while other WebGL sites will work (comment 0, comment 2, comment 6) and then Dave mentioned that the similar problem he was experiencing (comment 5) was actually a more generic one with WebGL (comment 7) ... so it works for Dave, not for me.

Happy to do more probing/testing as required, but WFM is an inappropriate resolution at this time!

Comment 10

[Victor Porof [:vporof][:vp]]

Ok, I only assumed we can close this because there weren't any replies to comment 8 for two weeks.

The current implementation testing if WebGL is available is based on https://bugzilla.mozilla.org/show_bug.cgi?id=689920#c37. See also comment no. 40 in there for details on what needed specifically tested.

As discussed, I added links to the code where enabling/disabling Tilt is done using nsIGfxInfo in comment 3 in this bug.

Mike, could you run this in a scratchpad in a browser environment? http://pastebin.mozilla.org/1433967

Benoit, is there anything else I need to test for besides FEATURE_NO_INFO for OPENGL and ANGLE using nsIGfxInfo?

Comment 11

[Benoit Jacob [:bjacob] (mostly away)]

My best guess is that WebGL is blacklisted on Mike's setup, but he has set the webgl.force-enabled preference to true. Mike, is that correct?

Tilt is explicitly querying the blacklist, but AFAIK isn't honoring the webgl.force-enabled and webgl.disabled preferences.

If my theory is correct, then I can see 3 possible solutions here:
 1. tweak Tilt to honor these preferences; or
 2. decide that Tilt does not honor them i.e. there's no bug here; or
 3. give up with querying the blacklist, just always try to create a WebGL context and see if it succeeds.

Comment 12

[Benoit Jacob [:bjacob] (mostly away)]

Maybe 3. would be best implemented by always showing the 3D button, only trying to create a WebGL context when it's clicked (that's expensive, roughly 0.1 second), show an error message and gray out the button if it fails.

Comment 13

[Benoit Jacob [:bjacob] (mostly away)]

(In reply to Mike Beltzner [:beltzner] from comment #4)
> It's a SONY VAIO Z, which I believe Asa and Mossop also have.
> 
> Driver info from about:support
> 
> Adapter Description  NVIDIA GeForce GT 330M
> Vendor ID            0x10de
> Device ID            0x0a2b
> Adapter RAM          1024
> Adapter Drivers      nvd3dumx,nvwgf2umx,nvwgf2umx nvd3dum,nvwgf2um,nvwgf2um
> Driver Version       8.16.11.9024

Alright, that's NVIDIA driver version 190.24, a very old (late 2009) version, it's blacklisted.

Comment 14

[Victor Porof [:vporof][:vp]]

(In reply to Benoit Jacob [:bjacob] from comment #11)
> My best guess is that WebGL is blacklisted on Mike's setup, but he has set
> the webgl.force-enabled preference to true. Mike, is that correct?
> 
> Tilt is explicitly querying the blacklist, but AFAIK isn't honoring the
> webgl.force-enabled and webgl.disabled preferences.
> 

We decided to do this right from the start. Talking with Dave, Mihai and other folks from the devtools team, we thought it was best not to ship Tilt to as many people as possible, but make sure Tilt works perfectly where it can. Thus, besides setting the webgl.force-enable pref to true, on machines with blacklisted drivers there's also the devtools.tilt.force-enable pref which needs to be set to true.

> If my theory is correct, then I can see 3 possible solutions here:
>  1. tweak Tilt to honor these preferences; or
>  2. decide that Tilt does not honor them i.e. there's no bug here; or
>  3. give up with querying the blacklist, just always try to create a WebGL
> context and see if it succeeds.

Querying nsIGfxInfo is done only when the Inspector is opened, not at browser startup, so I think it could basically be safe just to try creating a 3d context and see if that works, instead of checking for FEATURE_NO_INFO. We currently only do this once, but I'm ok with testing this every time the Inspector is opened in order to show or hide the 3D button.

For the reference, here's the https://wiki.mozilla.org/DevTools/Features/PageInspectorTilt page. See Functional specification details in there: "If the user's computer is not capable of GL, then the 3D button will not be displayed at all in the toolbar". I would be happy to change this, but a grayed out button would look ugly imho.

Comment 15

[Rob Campbell [:rc] (:robcee)]

(In reply to Benoit Jacob [:bjacob] from comment #12)
> Maybe 3. would be best implemented by always showing the 3D button, only
> trying to create a WebGL context when it's clicked (that's expensive,
> roughly 0.1 second), show an error message and gray out the button if it
> fails.

that doesn't sound like a great experience, tbh. Showing a feature, letting the user interact with it and then taking it away after a brief pause and potential graphical glitching doesn't sound like a great experience.

I'd prefer to do the querying up front.

Maybe allowing webgl.force-enabled to override the nsIGfxInfo probe is the way to go.

Comment 16

[Joe Drew (not getting mail)]

Benoit wasn't talking about interaction, just trying to create a WebGL context (canvas.getContext("webgl")). If that returns null, then grey out the button.

There is a possibility of graphical glitching if just _creating_ the webgl context can crash the driver, though.

Comment 17

[Victor Porof [:vporof][:vp]]

(In reply to Joe Drew (:JOEDREW!) from comment #16)
> Benoit wasn't talking about interaction, just trying to create a WebGL
> context (canvas.getContext("webgl")). If that returns null, then grey out
> the button.
> 

"create a WebGL context when [the button] is clicked, show an error message and gray out the button if it fails."

I think that counts as interaction, and I agree with Rob that we probably shouldn't do this. Also, creating a WebGL context can be done when the Inspector starts, to gray out the button before the UI is shown, not after the button is clicked.

> There is a possibility of graphical glitching if just _creating_ the webgl
> context can crash the driver, though.

This sounds like exactly the reason why we shouldn't touch getContext(). There's devtools.tilt.force-enabled for the adventurous :)

Comment 18

[Mike Beltzner [:beltzner, not reading bugmail]]

(In reply to Benoit Jacob [:bjacob] from comment #11)
> My best guess is that WebGL is blacklisted on Mike's setup, but he has set
> the webgl.force-enabled preference to true. Mike, is that correct?

Gah! Right you are, Benoit. Sorry about that.

> If my theory is correct, then I can see 3 possible solutions here:
>  1. tweak Tilt to honor these preferences; or

That makes most sense to me, as then we don't get into the confusing case I'm in, but I'd also respect the decision to go with one of those other options.

Resummarizing bug to reflect findings.

Comment 19

[Victor Porof [:vporof][:vp]]

(In reply to Mike Beltzner [:beltzner] from comment #18)
> 
> > If my theory is correct, then I can see 3 possible solutions here:
> >  1. tweak Tilt to honor these preferences; or
> 
> That makes most sense to me, as then we don't get into the confusing case
> I'm in, but I'd also respect the decision to go with one of those other
> options.

In this case, we keep the current implementation but also add a check for webgl.force-enable? (to avoid using getContext())

Comment 20

[Mike Beltzner [:beltzner, not reading bugmail]]

Yup, if (devtools.tilt.force-enabled false||webgl.force-enable)

Comment 21

[Benoit Jacob [:bjacob] (mostly away)]

(In reply to Victor Porof from comment #17)
> > There is a possibility of graphical glitching if just _creating_ the webgl
> > context can crash the driver, though.
> 
> This sounds like exactly the reason why we shouldn't touch getContext().
> There's devtools.tilt.force-enabled for the adventurous :)

Not really: getContext checks the blacklist and won't touch blacklisted drivers, so it's safe. The real reason to avoid touching getContext is that it's very slow (typically 100 ms).

Comment 22

[Victor Porof [:vporof][:vp]]

Attachment: [in-fx-team] v1

Comment 23

[Mihai Sucan [:msucan]]

Comment on attachment 588390 [details] [diff] [review]
[in-fx-team] v1

https://hg.mozilla.org/integration/fx-team/rev/8119541c7a7f

Comment 24

[Tim Taubert [:ttaubert] (inactive)]

https://hg.mozilla.org/mozilla-central/rev/8119541c7a7f

Comment 25

[Trif Andrei-Alin[:AlinT]]

Verified on Firefox 12.