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

Re: [Public WebGL] preserveDrawingBuffer = false

On 2011-04-28 00:51, Vladimir Vukicevic wrote:
----- Original Message -----
On 2011-04-20 03:56, Gregg Tavares (wrk) wrote:
I'd like to suggest that the preserveDrawingBuffer = false spec be

The spec was written so that the drawing buffer is cleared if a
compositing operation is done. This was done so that apps would not
rely on the contents of the drawing buffer being preserved.

Unfortunately it has the opposite effect. Apps are now written to
expect the drawing buffer to be cleared. But, the spec does not
actually require the drawing buffer to be cleared unless the buffer
is composited.

So, we have the same situation. Apps expect the drawing buffer to be
cleared but depending on the browser, timing, etc there is no
guarantee that the buffer was actually composited. If it wasn't the
contents is still there. You write some code, it seems to work and
only later do you find out that on some slow machine or some
specific browser on a specific platform you're getting inconsistent
behavior and tracking that down can be really hard (I just got
through tracking
it down for one app)

Would it be possible to change the spec to effectively say

      If preserveDrawingBuffer is false, then when JavaScript enters
callback if the user does not clear the drawingbuffer before the
first draw call the implementation will clear it?

This doesn't seem like it would change any of the performance issues
nor the effective semantics of the spec but it would make the
behavior 100% consistent.
Sounds good to me, I agree having it consistent in all cases would be
much better.
I don't think it's all that easy to know "when a callback is entered" without a lot of potentially expensive state tracking and checking that you'd have to do on every draw call.  I agree that consistency is important, but I don't think this is the right way to get it.  If apps are incorrectly relying on this, we should consider changing the "default clear" color to be a random non-black color (or explicitly specify hot pink) as a way of forcing apps to do the clear themselves.  We shouldn't be letting apps use this as a crutch for not clearing themselves.

In our implementation it would not be any overhead to always clear, but if changing the default clear color is easier to implement in other browsers I am fine with that. Doing so should also solve the issue in more or less all cases.


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