[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] vertexAttribPointer conformance test



I think we should make this change. Zhenyao Mo has been working on
updating the WebKit checks in this area and has a significant number
of changes to this test. He points out that we should probably change
the wording in spec section 5.3.10 for vertexAttribPointer from:

"Passed stride and offset must be appropriate for the passed type and
size or an INVALID_VALUE error will be generated..."

to:

"Passed stride and offset must be appropriate for the passed type or
an INVALID_VALUE error will be generated..."

to make it clear that the number of components per attribute is not
taken into account in the checks made against stride and offset.

Comments?

-Ken

On Wed, Jan 5, 2011 at 4:58 PM, Vladimir Vukicevic <vladimir@mozilla.com> wrote:
> In particular, the check in this test is written as:
>
>    if (st > 0 && st < bytesPerElement) {
>
> (where bytesPerElement is bytesPerComponent * size); I think it should be:
>
>    if (st > 0 && st % info.bytesPerComponent != 0) {
>
> Which seems to give the desired results.. that is:
>
> gl.vertexAttribPointer(0, 4, gl.SHORT, false, 2, 24) succeeds, but
> gl.vertexAttribPointer(0, 4, gl.SHORT, false, 3, 24) fails because the stride is invalid (results in an unaligned access)
>
>   - Vlad
>
>
> ----- Original Message -----
>> I think some of these changes are wrong -- I agree that we should
>> disallow (and I believe we already do and check for):
>>
>> size = 3, type = FLOAT, stride = 2
>>
>> but I do not think that we should disallow
>>
>> size = 3, type = FLOAT, stride = 4
>>
>> which the test currently does... the result here is perfectly valid,
>> from my reading of the spec.
>>
>> - Vlad
>>
>> ----- Original Message -----
>> > So I updated the test to test lots of combinations (checked in)
>> >
>> >
>> > That brings up more questions about the restrictions added in
>> > section
>> > 6.3
>> >
>> >
>> > 1st) "why the restrictions"
>> >
>> >
>> >
>> >
>> > Is there some situation we are trying to prevent that we need to
>> > prevent?
>> >
>> >
>> > 2nd) "why not more restrictions"
>> >
>> >
>> > As currently specified it's possible to set size = 4, type = byte,
>> > stride = 1. So as input to the shader you'll get
>> >
>> >
>> > vec4 (element0,element1,element2,element3)
>> > vec4 (element1,element2,element3,element4)
>> > vec4 (element2,element3,element4,element5)
>> >
>> >
>> > ...
>> >
>> > 3rd) "why INVALID_OPERATION"
>> >
>> >
>> >
>> >
>> > wouldn't INVALID_VALUE be more appropriate?
>> -----------------------------------------------------------
>> You are currently subscribed to public_webgl@khronos.org.
>> To unsubscribe, send an email to majordomo@khronos.org with
>> the following command in the body of your email:
>

-----------------------------------------------------------
You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email: