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

Re: [Public WebGL] WebGL back buffer contents



On Jan 26, 2010, at 6:38 AM, Kenneth Russell wrote:

> 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.


I would have no problem with such a definition.

-----
~Chris
cmarrin@apple.com




-----------------------------------------------------------
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: