[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] gl.sizeInBytes
On Mon, Jan 11, 2010 at 9:17 PM, Kenneth Russell <email@example.com> wrote:
> On Mon, Jan 11, 2010 at 12:31 PM, Vladimir Vukicevic <firstname.lastname@example.org>
>> On 1/11/2010 11:48 AM, Kenneth Russell wrote:
>> On Mon, Jan 11, 2010 at 10:37 AM, Chris Marrin <email@example.com> wrote:
>>> So then maybe it would be better to replace these with constants
>>> (ctx.FLOAT_SIZE, ctx.INT_SIZE, ctx.UNSIGNED_SHORT_SIZE), etc.?
>> I think we should leave sizeInBytes as a function rather than defining
>> constants. On a hypothetical platform which defined GLfloat as a double, the
>> WebGL implementation would be responsible for making WebGLFloatArray manage
>> double-precision rather than single-precision floating point numbers.
Why does this matter for function vs constant? The WebGL spec could
define ctx.FLOAT_SIZE etc to return implementation-dependent values,
the same as sizeInBytes would return. (Maybe that conflicts with
WebIDL's notion of "constant", but it could be defined as a property
with a getter that returns the implementation-dependent value, so it's
the same API syntax and implementation as a constant, as far as I'm
aware). The only difference for function vs constant seems to be
syntax ("gl.sizeInBytes(gl.FLOAT)" vs "gl.FLOAT_SIZE"), so it should
be decided on ease-of-use rather than on implementation issues.
>> We already have the exact size of the machine types specified for the
>> WebGL Arrays; I think that this needs to remain the case, because otherwise
>> we have the problem that people will just assume 4 bytes anyway because it's
>> currently the probably-100% case and the world breaks if there is an 8-byte
>> "GL_FLOAT" platform. Otherwise, people have to use sizeInBytes constantly
>> to get correct portable behaviour, and we've tried pretty hard to avoid
>> requirements like that (e.g UniformIndex and friends)..
> For completely portable behavior, we could consider changing the WebGL spec
> to say for example that the WebGLFloatArray contains floating-point values
> compatible with the GLfloat typedef on the host platform.
> I agree that realistically no OpenGL implementation is going to typedef
> GLfloat to double. However, if there were one that did, it would be more
> likely that a C program would work after recompilation than a WebGL program,
> because struct alignment and the sizeof operator would "just work". If we
> keep the sizeInBytes function and encourage programmers to use it, WebGL
> code could be as robust.
If you make it possible (but not necessary) for web programmers to do
the right thing, some will and some won't. Somebody implementing a web
browser with WebGL would want to work with all the existing WebGL
applications that have been published (otherwise the browser's users
will complain that their favourite demos don't work), and some of them
won't be doing the right thing. (Given past experience, probably a
very high proportion won't do the right thing). So the web browser
would have to preserve the assumptions that authors make (e.g. that
floats are 4 bytes), and do fixups internally if that's inconsistent
with the host environment. Even if the fixups are slow and hard to
implement, the cost would be less than the cost of getting everybody
on the web to fix their code, and probably less than the cost of
unhappy users. The problem for browser implementors is the same if you
don't give authors the option of writing portable code at all, so the
option does not even help the hypothetical portability situation, and
so this doesn't seem to me like a valid reason to provide the feature.
You are currently subscribe to firstname.lastname@example.org.
To unsubscribe, send an email to email@example.com with
the following command in the body of your email: