Closed Bug 557516 Opened 14 years ago Closed 14 years ago

gl_PointSize ignored in vertex shaders

Categories

(Core :: Graphics: CanvasWebGL, defect)

Product:
Core
Component:
Graphics: CanvasWebGL
Platform:
x86
Windows 7
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: giles, Unassigned)

References

(
URL
)

Details

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

According to the the OpenGL ES Shader Language 1.0 specification, vertex shaders can set gl_PointSize to control the pixel size of point sprites.  In Minefield, this does not work unless the code "gl.enable(0x8642);" is executed in the JavaScript at some point prior to drawing the points.  If the "enable" code is not called, the points are drawn one pixel in size regardless of the value gl_PointSize is set to.

Looks like part of the fixed-function pipeline is still there and shouldn't be.  0x8642 is the numerical value of GL_VERTEX_PROGRAM_POINT_SIZE, and desktop implementations of OpenGL apparently require that to be enable to make setting gl_PointSize work.  This requirement is not part of OpenGL ES 2.0 / WebGL.

Reproducible: Always

Steps to Reproduce:
1. With a WebGL-enabled Minefield, go to http://learningwebgl.com/lessons/example03/particles-01-noenable.html

Actual Results:  
If you look closely, you'll see explosions of point sprites.  (They're hard to see as each point is just 1 pixel in size.)

Expected Results:  
With a WebGL-enabled Minefield, go to http://learningwebgl.com/lessons/example03/particles-01.html -- this is a version of the previous page with an explicit enable of 0x8642, and works as expected.

FYI Chromium shows the same problem.
Uh... things seem to have changed since you reported this.

This pname value 0x8642 is not rejected by enable() as it's not a valid pname; so it has no effect; but what's worrying me is that I can't see anything in your scene. Is it working for you, with current minefield?
Just tried it with last night's built, and both of the sample pages (that is, both the one I expected to succeed and the one I expected to fail) worked perfectly!

I'm running on Windows Vista, ATI 2400HD graphics.  I also checked it over the weekend (with, I think, Friday's build) on my laptop -- Windows 7, ATI mobile graphics -- and both pages worked there to.
ok, let's call this a WORKSFORME :)
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Resolution: --- → WORKSFORME
If you want -- though I thought it didn't work for you?  ("Works for me, for restricted values of 'me'" ;-)
The thing is, looking at the code at hand, I really don't see how it could be anything else than a driver bug :/ indeed, I can't see any sprites, all I see is a blank widget. I'm using the proprietary nvidia driver, so I can't even investigate :/
Fair enough.  I guess Jacob Seidelin's "Worlds of WebGL" doesn't work for you either?
Actually, it does!
Hmm.  Now that's really odd! I wonder what he's doing differently?  He was the one who suggested using the weird gl.enable of a raw hex value to make it work...
At this stage it saves a lot of time to declare that it's "probably" a driver bug on my side ;-)

Also, above i wrote "This pname value 0x8642 is not rejected by enable()" but I made a typo, I meant "now" instead of "not".
Reopening.

I just saw that we have this code:


#ifndef USE_GLES2
    // gl_PointSize is always available in ES2 GLSL, but has to be
    // specifically enabled on desktop GLSL.
    gl->fEnable(LOCAL_GL_VERTEX_PROGRAM_POINT_SIZE);
#endif


So we are actually doing this glEnable() on desktop OpenGL. (Regardless of the fact that this is not a valid WebGL enable() pname, under the hood we do it on desktop openGL).
(ignore the "reopening" in above comment)
Excellent, perhaps that line was added sometime after I originally saw the problem.  If you feel like changing the status, perhaps it's really resolved/fixed :-)
As it turns out, setting the point size is just plain unsupported on ATI Radeon cards :-(
You need to log in before you can comment on or make changes to this bug.