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

RE: [Public WebGL] Out-of-bounds ReadPixels and CopyTex*Image* behavior

I am good with this.  I wish we had done it sooner as it would have saved me from writing a bunch of (now) unnecessary code.


From: owners-public_webgl@khronos.org [mailto:owners-public_webgl@khronos.org] On Behalf Of Kenneth Russell
Sent: Monday, November 2, 2015 5:03 PM
To: Jeff Gilbert <jgilbert@mozilla.com>
Cc: webgl, public <public_webgl@khronos.org>
Subject: Re: [Public WebGL] Out-of-bounds ReadPixels and CopyTex*Image* behavior


Thanks for proposing this and sorry for the delay reviewing it.


This change sounds good to me. It's hard to imagine that applications are relying on the behavior of returning zero for out-of-bounds pixels during reads. Changing this for both WebGL 1.0 and 2.0 at the same time sounds fine to me; no reason to make the specs diverge further.


Any other feedback from implementers? There aren't that many conformance tests for this behavior, so it should be straightforward to update the spec and those tests, and remove the invalidated tests from earlier versions of the conformance suite.


Assuming no objections, would you be willing to assemble a pull request for both the spec and conformance test changes?







On Fri, Oct 30, 2015 at 6:03 AM, Jeff Gilbert <jgilbert@mozilla.com> wrote:

We standardized this to read zeros in WebGL 1. However, this is
trickier in WebGL 2 because of PBOs and the new PACK_ pixelstore

I propose that we change this (at least for WebGL 2) to "Out-of-bounds
pixels are not written to the destination during reads from a
framebuffer (ReadPixels or CopyTex*Image*), leaving the values in the
destination buffer unchanged. Partially-out-of-bounds reads will only
write in-bounds pixels to the destination buffer."

This should be at easy or easier to implement, and be much more
performant, since implementations can just restrict the size of their
read and draw rects for these operations.

I would really rather make out-of-bounds reads of this sort an
INVALID_OPERATION, but a change to an error is more likely to be
breaking in terms of existing content. While it's also a breaking
change from OpenGL, I don't believe it is a porting concern, since
porting can be fixed by changing its behavior to match what I outline
above at the Emscripten (or other) level, though.

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