[Public WebGL] WebGL back buffer contents

Vangelis Kokkevis [email protected]
Tue Jan 26 10:00:11 PST 2010


On Tue, Jan 26, 2010 at 6:38 AM, Kenneth Russell <[email protected]> wrote:

> On Tue, Jan 26, 2010 at 12:59 AM, Tim Johansson <[email protected]> wrote:
> > On 1/25/10 11:43 PM, Chris Marrin wrote:
> >>
> >> Generally, these are all good questions. More inline...
> >>
> >> On Jan 25, 2010, at 2:11 PM, Gregg Tavares wrote:
> >>
> >>
> >>>
> >>> Something that's not clear to me still is how WebGL knows what's in the
> >>> backbuffer.
> >>>
> >>> If I do something like
> >>>
> >>> window.setInterval(drawNextTriangle, 1);
> >>>
> >>> function drawNextTriangle() {
> >>>   ctx.drawElements(...);
> >>> };
> >>>
> >>> Then what will I see on the screen? Is it defined?
> >>>
> >>
> >>
> >
> > I think that is not defined, but it probably should be because authors
> will
> > do such things.
> >>
> >> I'm not sure what you mean here. This should draw a new triangle every
> ms,
> >> right? Depending on how fast your browser can service the setInterval,
> it
> >> will draw a new triangle at that rate. Theoretically every ms, but I
> believe
> >> most browsers will throttle that down to something much lower.
> >>
> >>
> >
> > Right, but after each draw call the content could theoretically be reset
> to
> > a different back buffer or cleared to black since that behavior is not
> > specified as far as I know.
> > You would get either all triangles, every second triangle (switching if
> it
> > is even or odd numbered triangles visible) or you could get just the last
> > triangle.
> >>>
> >>> I posted the 3rd example because section 2.2 of the spec says after
> >>> compositing the contents of the backbuffer are undefined which suggests
> to
> >>> me that second drawImage call will have undefined results? Am I
> >>> mis-interpreting the spec?
> >>>
> >>
> >> The "undefined" bit was put there so that different swapping models
> could
> >> be afforded. But since direct rendering of the WebGL content is not
> really
> >> possible (it has to be composited by HTML to have the proper layering),
> I
> >> would have no trouble saying that the contents of the drawing buffer are
> >> valid until changed by a clear() or further drawing calls.
> >>
> >>
> >
> > I think a specific behavior will be required to be compatible with web
> > content anyway, so I am not against specifying this in some way.
>
> I think we should settle on having the contents of the WebGL drawing
> buffer be persistent, like the 2D context. Having a completely new
> back buffer potentially swapped in unexpectedly will be too surprising
> to the programmer.
>
> -Ken
>

I like that idea although I'm not sure how we would handle resizing of
drawing surface.  What's the expectation then?

Vangelis


>
> -----------------------------------------------------------
> You are currently subscribe to [email protected]
> To unsubscribe, send an email to [email protected] with
> the following command in the body of your email:
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20100126/29336d95/attachment.html>


More information about the public_webgl mailing list