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

Re: [Public WebGL] WebGL back buffer contents



On Tue, Jan 26, 2010 at 12:59 AM, Tim Johansson <timj@opera.com> 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

-----------------------------------------------------------
You are currently subscribe to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email: