[Public WebGL] readPixels overloads?

Boris Zbarsky [email protected]
Fri Apr 20 20:31:01 PDT 2012


On 4/20/12 11:22 PM, Glenn Maynard wrote:
>     Thinking about readPixels some more, would it make sense to add an
>     overload like this to the spec:
>
>       void readPixels(GLint x, GLint y, GLsizei width, GLsizei height,
>                       ArrayBufferView? pixels)
>
>     which assumes format=RGBA and type=UNSIGNED_BYTE?  If one really
>     wanted, one could even make it take a Uint8Array; I think the
>     current behavior of allowing passing in the wrong array types but
>     "silently" not writing data to them is sorta hostile as APIs go.
>
> The problem wouldn't exist if functions threw exceptions for invalid
> enum arguments (and other things which are almost always programming
> errors and which can be detected without flushing the render queue), but
> failing that it doesn't seem worth sidestepping it for just a single API
> call.  Other functions do the same thing if you pass an invalid enum (do
> nothing except generate an error).

The main problem I'm trying to solve here is not the "do nothing" 
behavior but  "this function requires two arguments whose values must 
always be the same constant, which seems like bad API".

>     This would not break existing code (or future code if more
>     modes/formats ever get added), since the old overload would still be
>     there, but would allow simpler code to be written in the meantime.
>
> (Omitting two parameters here isn't much of a simplification--this isn't
> a function that's used a whole lot; rarely more than once or twice in an
> application, if that.)

<shrug>.  Just pointing out things that would make me, as someone not 
intimately familiar with WebGL, go "WTF?" if I had to write code to the API.

-Boris

-----------------------------------------------------------
You are currently subscribed to [email protected]
To unsubscribe, send an email to [email protected] with
the following command in the body of your email:
unsubscribe public_webgl
-----------------------------------------------------------





More information about the public_webgl mailing list