[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] Move flipY and asPremultipliedAlpha parameters out of DOM helpers
This brings up a good point.
Using the OpenGL it's possible to update a sub region in a local buffer when calling readPixels.
static char rgba_buffer[256x256x4];
// Update just a corner of rgba_buffer
glReadPixels(192, 192, 64, 64, GL_RGBA, GL_UNSIGNED_BYTE, &rgba_buffer[(192*256+192) * 4]);
While OpenGL ES doesn't currently support GL_PACK_ROW_LENGTH should the WebGL readPixels signature change in anticipation of supporting things like that?
Currently readPixels returns a ArrayBufferView. If instead it required an ArrayBufferView to be passed in we could in the future support GL_PACK_ROW_LENGTH. We'd also remove the readPixels during lost context issue and probably end up with a much faster path then we have now where every call to readPixels requires giant memory allocations.
Bascially, readPixels should change to
void readPixels(GLint x, GLint y, GLsizei width, GLsizei
GLenum format, GLenum type, ArrayBufferView destinationBuffer)
With the restrictions that whatever width, height and the various state settings of pixelStore define will be enforced by WebGL. In other words, if destinationBuffer is not big enough to handle the request then INVALID_OPERATION is generated.
On Sun, May 23, 2010 at 7:25 PM, Mark Callow <email@example.com>
On 20/05/2010 08:44, Cedric Vivier wrote:> the order of the two arguments ...
> After looking/playing with the DOM helper signature for a while I
> believe that flipY and asPremultipliedAlpha should not be here :
> - they are 'alien' to the standard texImage2D signature (one could
> argue that this is the case for HTMLImageElement as well - but the
> whole point for the helper signatures imho is to help treat the DOM
> element parameter as if it was a proper *pixels pointer, this is
> easily guessable too even without knowing WebGL but only OpenGL).
> - behavior of flipY and asPremultipliedAlpha is not obvious when
> reading code, those two booleans after 'element' cannot be guessed
> without looking at documentation, worse, it is easy to forget or mix
Another really good reason for moving flipy from the TexImage2D
signatures is that a future version of GL ES will provide this
functionality but as part of the pixel store parameters not the
TexImage2D command. Since this is a public forum, I can't say much more
The traditional way to avoid the confusion you mention is to use enums
or defines instead of true & false Another way to alleviate it is to put
both parameter name and type in the function signature. I don't know if
either are applicable to IDL.