Closed Bug 524148 Opened 15 years ago Closed 14 years ago

[webgl] with hardware rendering, using a mixture of vertexAttribPointer and vertexAttrib4f for one drawArrays does nothing

Categories

(Core :: Graphics: CanvasWebGL, defect)

x86
Windows Vista
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: giles, Unassigned)

References

()

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.3a1pre) Gecko/20091020 Minefield/3.7a1pre GTB5 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.3a1pre) Gecko/20091020 Minefield/3.7a1pre GTB5 (.NET CLR 3.5.30729)

In the sample WebGL code linked above, a triangle and a square are drawn.  The triangle has both vertex positions and colours specified using vertexAttribPointer.  The square has its vertex positions specified using vertexAttribPointer, and a single colour specified using vertexAttrib4f.

The sample renders correctly in Minefield -- both triangle and square showing -- when using MESA with software rendering switched on, and it also renders correctly on WebKit.  However, when using Minefield with software rendering switched off, the square does not display.

Caveat: I've only been able to test this with one machine, so it may be graphics hardware specific.  If that is the case, it might be useful for you to know that the chipset is an ATI Radeon HD 2400 Pro.

Reproducible: Always

Steps to Reproduce:
1. Using Minefield with software rendering switched off, go to http://learningwebgl.com/bug-repro/singlevertexattr-minrepro.html

Actual Results:  
The square will be missing

Expected Results:  
You should see the square :-)
WFM here, but with nvidia hardware.. could be some ATI driver bug?
It could be -- is there anything I could do to find out?  I've upgraded to the latest drivers but the problem's still there.  I've not noticed any problems with other 3D software.

Perhaps we can wait until the dev Chrome has WebGL enabled and then see if it occurs in that too -- if it does, we can be reasonably sure that it's a driver issue.  If it doesn't then I guess the diagnosis is less sure...
This really shouldn't affect things, but move the enableVertexAttrib calls after the vbo is created and fully populated (that is, after the vertexAttribPointer call).

Also explicitly disable it after the triangle drawArrays and then enable vertexPositionAttribute after he next vertexAttribPointer.  I've got an ATI box here that's working now, so I'll give it a shot here as well.
Thanks for the suggestion; unfortunately it doesn't seem to have had an effect.  Just for safety's sake, here's the code:


  function drawScene()
  {
    gl.clear(gl.COLOR_BUFFER_BIT | gl.DEPTH_BUFFER_BIT)

    var trianglePositionBuffer = gl.createBuffer();
    gl.bindBuffer(gl.ARRAY_BUFFER, trianglePositionBuffer);
    var vertices = [
        -0.5,  0.5,  0.0,
        -1.0, -0.5,  0.0,
         0.0, -0.5,  0.0
    ];
    gl.bufferData(gl.ARRAY_BUFFER, new CanvasFloatArray(vertices), gl.STATIC_DRAW);
    gl.vertexAttribPointer(vertexPositionAttribute, 3, gl.FLOAT, false, 0, 0);

    var triangleColorBuffer = gl.createBuffer();
    gl.bindBuffer(gl.ARRAY_BUFFER, triangleColorBuffer);
    var colors = [
        1.0, 0.0, 0.0, 1.0,
        0.0, 1.0, 0.0, 1.0,
        0.0, 0.0, 1.0, 1.0,
    ];
    gl.bufferData(gl.ARRAY_BUFFER, new CanvasFloatArray(colors), gl.STATIC_DRAW);
    gl.vertexAttribPointer(vertexColorAttribute, 4, gl.FLOAT, false, 0, 0);

    gl.enableVertexAttribArray(vertexPositionAttribute);
    gl.enableVertexAttribArray(vertexColorAttribute);
    gl.drawArrays(gl.TRIANGLES, 0, 3);

    gl.disableVertexAttribArray(vertexColorAttribute);

    squarePositionBuffer = gl.createBuffer();
    gl.bindBuffer(gl.ARRAY_BUFFER, squarePositionBuffer);
    vertices = [
         1.0,  0.5,  0.0,
         0.0,  0.5,  0.0,
         1.0, -0.5,  0.0,
         0.0, -0.5,  0.0
    ];
    gl.bufferData(gl.ARRAY_BUFFER, new CanvasFloatArray(vertices), gl.STATIC_DRAW);
    gl.vertexAttribPointer(vertexPositionAttribute, 3, gl.FLOAT, false, 0, 0);

    gl.vertexAttrib4f(vertexColorAttribute, 0.5, 0.5, 1.0, 1.0);

    gl.enableVertexAttribArray(vertexPositionAttribute);
    gl.drawArrays(gl.TRIANGLE_STRIP, 0, 4);
  }



...I also tried this with the call to gl.disableVertexAttribArray(vertexColorAttribute) placed immediately before the triangle strip drawArrays call.
I've managed to test this with WebKit, and I get the same result.  (I also found that they're throwing a "Syntax Error" exception in similar, but not identical circumstances.)

Presumably that means that the problem's not with Firefox and this ticket can be closed -- though I'd be grateful if you could suggest a good place to report it...
Sorry, a little more detail on the test where I repro'd the problem with WebKit -- it was using the very latest nightly Chromium from here: http://build.chromium.org/buildbot/continuous/LATEST/

And, of course, it was on the same machine where I see the problem in Firefox.

A commenter on my blog seems to have a similar problem, and is using a ATI x1600 mobile graphics card, which would seem to support Vlad's suspicion that it's an ATI driver bug.
OK, having thought about this in depth; my hypothesis is that the ATI OpenGL driver -- as used by both WebKit and Firefox -- is treating a call to drawArrays with one attribute set by a buffer and one set individually, as if there was only one vertex to draw, so it's doing nothing.  (I've confirmed that it's not just the colour getting lost or set to zero by changing the fragment shader in the repro code to always return white; there's no change in the effect.)

On this basis, while I'm sure someone somewhere -- perhaps at ATI -- would love to know about the bug, I'm just going to change my WebGL tutorials so that we always use buffers; I imagine that objects with large numbers of vertices all the same colour is unlikely to be a hugely common use case anyway, so there's little point in harping on about it in a set of introductory lessons.
Component: Canvas: 2D → Canvas: WebGL
QA Contact: canvas.2d → canvas.webgl
Going to close this off as I don't think there's anything that we need to do here -- note also that vertex attrib 0 is "special" and basically always has to be an array for anything to render on desktop GL.  That's not the case for GL ES, but we have to enforce the desktop GL semantics even on WebGL (I don't think that we're doing this correctly yet, but perhaps it's happening inadvertently).
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.