634506 - gl.linewidth in WebGL no longer works

Status: RESOLVED INVALID

(Core :: Graphics: CanvasWebGL, defect)

Description

[Ed]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/534.21 (KHTML, like Gecko) Chrome/11.0.673.0 Safari/534.21
Build Identifier: 4.0b12pre (2011-02-15)

WebGL.linewidth (a WebGL function to set the active line width) used to correctly scale the line width in the 4.0b9pre (2010-12-31) build but results in a line one pixel wide in the latest version.

Reproducible: Always

Actual Results:  
The line width appears to always be a single pixel wide.

Expected Results:  
The line should have been scaled by the specified line width

Comment 1

[Boris Zbarsky [:bzbarsky]]

Ed, could you attach or point to a testcase?

Comment 2

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

Nothing changed on our side, but what changed is that we now use ANGLE for rendering by default. Can you go to about:config and set webgl.prefer-native-gl ? Does this make a difference? What's your GPU vendor?

Comment 3

[Ed]

Attachment: Testcase - linewidth.html to demonstrate the problem

Testcase (shamelessly plagiarized from "lesson1") demonstrating that linewidths are not scaled. Works in referenced earlier version of Minefield but does not work in current version.

Comment 4

[Ed]

Attachment: Testcase support javascript file

Comment 5

[Ed]

Attachment: Testcase support javascript file

Comment 6

[Ed]

(In reply to comment #2)
> Nothing changed on our side, but what changed is that we now use ANGLE for
> rendering by default. Can you go to about:config and set webgl.prefer-native-gl
> ? Does this make a difference? What's your GPU vendor?

GPU is Nvidia Quadro FX 2700M

Using webgl.prefer-native-gl makes no difference - linewidths are still not scaled in latest version.

Comment 7

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

Here on linux / NVIDIA your testcase works: the shape on the right is using thicker lines.

So that's a problem: I can't reproduce at the moment.

Can you please go to about:support, copy to clipboard, and paste the Graphics section here:
 * with default preferences
 * with webgl.prefer-native-gl=true

Also, the next very useful thing to do would be to bisect it using our archive of nightly builds:
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/
(use the mozilla-central directories)

Comment 8

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

Hah, I can reproduce in Win7 / NVIDIA Quadro FX 880 M using ANGLE (the default) for rendering.

But when I use desktop OpenGL instead of ANGLE for rendering (go to about:config and set webgl.prefer-native-gl=true), the problem goes away.

Are you *sure* that you can reproduce the problem with webgl.prefer-native-gl=true? If yes, what's your driver version?

Comment 9

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

This has already been reported as an ANGLE bug:
   http://code.google.com/p/angleproject/issues/detail?id=119

Comment 10

[Ed]

So here's the info from about:support with webgl.prefer-native-gl=true. I note that the modified setting does not show up below... not sure if that means it's not been changed or whether you are just not outputting it. If I go to about:config the webgl.prefer-native-gl entry is set to true and is in bold typeface. Restarting Firefox does not help either.

  Modified Preferences

      Name

      Value

        accessibility.typeaheadfind.flashBar
        0

        browser.places.importBookmarksHTML
        false

        browser.places.smartBookmarksVersion
        2

        browser.startup.homepage
        http://www.msn.com/|http://www.google.com/

        browser.startup.homepage_override.buildID
        20110217030357

        browser.startup.homepage_override.mstone
        rv:2.0b12pre

        browser.tabs.loadInBackground
        false

        browser.tabs.warnOnClose
        false

        dom.max_script_run_time
        0

        extensions.lastAppVersion
        4.0b12pre

        network.cookie.prefsMigrated
        true

        places.history.expiration.transient_current_max_pages
        104612

        places.last_vacuum
        1277323837

        privacy.sanitize.migrateFx3Prefs
        true

        security.warn_viewing_mixed
        false

  Graphics

        Adapter Description
        NVIDIA Quadro NVS 290

        Vendor ID
        10de

        Device ID
        042f

        Adapter RAM
        Unknown

        Adapter Drivers
        nv4_disp

        Driver Version
        6.14.11.6255

        Driver Date
        8-4-2007

        Direct2D Enabled
        Blocked on your graphics driver. Try updating your graphics driver to version 257.21 or newer.

        DirectWrite Enabled
        false (0.0.0.0, font cache n/a)

        WebGL Renderer
        Google Inc. -- ANGLE -- OpenGL ES 2.0 (ANGLE 0.0.0.541)

        GPU Accelerated Windows
        0/1

Comment 11

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

Oh, you have NVIDIA driver version 162.55. As this message says, you should try to upgrade to 257.21 or newer. Do you currently have webgl.force-enabled=true? Otherwise your driver version is blacklisted.

Comment 12

[Ed]

So if this is an issue with ANGLE then there's not much we can do... Even if the prefer-native-gl setting were to work, I don’t want to ask users to change their settings.

I just loaded Chromium and I see that the line width scaling does not work there
either - not sure if they are using ANGLE too but I would expect so?

Just to close the loop I will try loading the latest driver and let you know what I find.

From my perspective, I would rate this bug as a 'very nice to have' and here's
a use case for supporting it (rather than drawing the line with triangles which
is the only other alternative):

Our application is CAD - sometimes you have lines on a drawing that have no
physical width yet they have to be drawn along with other physical data. For
instance consider dimensioning lines on a CAD drawing - they want to be a few
pixels wide yet as you zoom in the line width needs to remain constant. This
would not happen if you constructed the line from triangles because they would
be in world coordinates and would get wider as you zoom into the drawing. Yes,
we will have to use LINES and live with them being one pixel wide but they
really don't show up very well and need to be a few pixels wide. 
There are other use cases too, along these lines, where the line doesn't
represent anything physical so it's width needs to remain constant as you zoom
into the design.

As I say, it's a 'very nice to have' feature - but I have to say that it's the
only thing that I know of that doesn't work and I find that awesome on a project of this magnitude! Thanks for your hard work - much appreciated.

Comment 13

[Ed]

(In reply to comment #11)
> Oh, you have NVIDIA driver version 162.55. As this message says, you should try
> to upgrade to 257.21 or newer. Do you currently have webgl.force-enabled=true?
> Otherwise your driver version is blacklisted.

Just to close the loop, if I install the latest driver AND I enable webgl.prefer-native-gl then line width scaling works as expected. So the problem is ANGLE and without support for gl.linewidth in ANGLE then I need to come up with a Plan B...

Thanks. Ed

Comment 14

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

Note that the OpenGL spec does not require wide lines to be actually available, AFAIK. You have to query for the max line width using getParameter(ALIASED_LINE_WIDTH_RANGE).

Comment 15

[Ed]

(In reply to comment #14)
> Note that the OpenGL spec does not require wide lines to be actually available,
> AFAIK. You have to query for the max line width using
> getParameter(ALIASED_LINE_WIDTH_RANGE).

I know, you are absolutely correct but, practically, I have not found an OpenGL implementation which doesn't support line widths up to say, 5 pixels (even 10, I think).

In which case, the "problem" with ANGLE would seem to be that it's going to force WebGL to take the lowest common denominator of functionality available in DirectX.

Comment 16

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

Note that WebGL is already aligned to an even much lower common denominator: what is actually supported on cell phones through OpenGL ES 2.0.

Comment 17

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

(In reply to comment #15)
> In which case, the "problem" with ANGLE would seem to be that it's going to
> force WebGL to take the lowest common denominator of functionality available in
> DirectX.

Not really; just like with real GL, you have to query.  DirectX can't do thick lines, iirc -- which is where the limitation comes from.