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

Re: [Public WebGL] Question about WebGL specification regarding getAttachedShaders



The returned values should be objects - and they should be persistent (that means that two calls to getAttachedShaders should return the same objects that I called attachShader with). I've built apps (and I've seen many others) that depend on this being the case.


On Thu, Sep 27, 2012 at 10:07 PM, Christoph Martens <christoph@martens.ms> wrote:

Hello everyone,

I'm currently implementing the WebGL spec for my V8GL runtime that will target all kinds of mobile and desktop platforms and I got into a question about the usage of typical WebGL APIs because I'm unsure if this is the wanted approach.

Due to having no primitives linked in _javascript_, it makes sense to abstract a couple of APIs that way in which you are able to get the buffers back (as arrays). My question is mostly about the concept behind getAttachedShaders() in the spec - from the implementors side.


My current implementation of the gl.getAttachedShaders() does the following:

- use first argument as programs GLuint
- glGetProgramiv((GLuint) program, GL_ATTACHED_SHADERS, (GLint*) maxCount);
- glAttachedShaders((GLuint) program, (GLsizei) *maxCount, (GLsizei*) countBuffer, (GLuint*) shadersBuffer)
- create v8::Uint32 array out of the returned shadersBuffer
- return the v8::Uint32 array


The code is located here on github, linked line may change due to further work:

https://github.com/martensms/lycheeJS-adk/blob/master/v8gl/src/binding/webgl.cpp#L161


Is this the wanted approach for the gl.getAttachedShaders() method?

I think I was just curious because I didn't see a requirement to have a _javascript_-side WebGLShader data type as all of the APIs seem to be able to be implemented without it.


Thank you :)
~Christoph

--
-- sent from my Notebook

Christoph Martens
informatics student, former _javascript_ engineer at Zynga

linux core dev, hardcore v8 hacker, w3c member (webapp, css & svg)


-----------------------------------------------------------
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:
unsubscribe public_webgl
-----------------------------------------------------------