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

Re: [Public WebGL] copyTexImage2D and copyTexSubImage2D



----- Original Message -----
> Hi list,
> 
> I am still waiting for input on my question.
> 
> For copyTexSubImage2D, there are two available options for undefined
> pixels (that are outside framebuffer boundaries).
> 
> 1) clamp, so these pixels stay the same before/after copyTexSubImage2D
> 2) set to 0

I would like us to standardize on 2) set to 0, for example because, as you mention, this is what we're already specing for readPixels().

Benoit

> 
> One way or the other, I think we should explicitly specify it in the
> WebGL spec. This has the potential of leaking information, so we
> definitely need to have a conformance test for it. However, before we
> decide to go 1) or 2), it's hard to write the test.
> 
> Mo
> 
> On Thu, Dec 23, 2010 at 2:23 PM, Mo, Zhenyao <zhenyao@gmail.com>
> wrote:
> > Ok, but that doesn't cover the case for copyTexSubImage2D. We can
> > initialize undefined pixels to 0 or make sure they stay untouched. I
> > am fine with either, but I think we should specify one so we could
> > test against it. Otherwise there is no way to write a test.
> >
> > On Thu, Dec 23, 2010 at 2:18 PM, Gregg Tavares (wrk)
> > <gman@google.com> wrote:
> >> This is mostly already speced.
> >>
> >> Section 4.1
> >> "WebGL resources such as textures and vertex buffer objects (VBOs)
> >> must
> >> always contain initialized data, even if they were created without
> >> initial
> >> user data values"
> >>
> >>
> >>
> >> On Thu, Dec 23, 2010 at 9:58 AM, Mo, Zhenyao <zhenyao@gmail.com>
> >> wrote:
> >>>
> >>> In WebGL spec, we say "For any pixel lying outside the frame
> >>> buffer,
> >>> the value read contains 0 in all channels" for readPixels.
> >>> Shouldn't
> >>> we say the same thing for copyTexImage2D?
> >>>
> >>> As in the case of copyTexSubImage2D, pixels outside the frame
> >>> buffer
> >>> could be cleared to 0, or could be untouched. The latter would be
> >>> more efficient. However, whatever way we decide, it should be made
> >>> explicit, so we could have conformance test against it.
> >>> "Undefined"
> >>> is unacceptable for security reasons.
> >>> -----------------------------------------------------------
> >>> 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:
> >>>
> >>
> >>
> >
> 
> -----------------------------------------------------------
> 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:
-----------------------------------------------------------
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: