[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] Ambiguity and Non-deterministicness in the WebGL Spec
On Thu, Dec 16, 2010 at 8:37 AM, Chris Marrin <email@example.com> wrote:
> On Dec 16, 2010, at 1:27 AM, Tim Johansson wrote:
>>>> ...So I'd rewrite as "By default (what does that mean? ed) after compositing the contents of the drawing buffer are undefined but are guaranteed not to contain information from another process." Then add a non-normative note somewhere that "One way to an implementation can guarantee buffers do not contain information from another process is to clear the buffer to the default values specified in OpenGL ES."
>>>> This gives maximum flexibility to the implementation while maintaining security.
>>> These words sound good. I have incorporated them into the spec in section 2.2.
>> Like I said in a previous mail I think this is a mistake. Leaving it undefined essentially means you will have to check what the most common implementations are doing and do the same thing. If you do anything else there is a high probability that content will not work since it relies on the behavior of the most common implementations.
>> Saying something is undefined does not mean implementations can choose to do whatever they want. If most desktop implementations keep the old value, which would be compliant with the spec and not very surprising since you need to be able to do that in the other mode, you can probably not make the optimizations you want on mobile without breaking content, even if you are still compliant with the spec.
> I think it's a mistake to "over-spec" this feature just so every browser works the same. As I'm arguing in another thread, iOS uses a different rendering model that most desktop implementations. And I expect that other mobile platforms will have some differences as well. If we over-specify, it can lead to implementations having to do non-optimal things just to comply with the spec.
> I think in most cases the spec needs to be very rigorous in its compliance requirements. But in cases where performance is at stake I think it would be the bigger mistake to require exact compliance.
I agree with Tim. On desktop platforms the easiest thing for a WebGL
implementation to do will be to preserve the previous frame's contents
(or that from two frames ago), even when the new preserveDrawingBuffer
context creation attribute is false. Applications will begin to rely
on that behavior and then break when transferred to mobile phones that
work very differently. This will probably force WebGL implementations
on mobile hardware to maintain compatibility with the desktop
implementations by always preserving the drawing buffer. The attendant
performance cost will be much higher than if there were an implicit
clear of the drawing buffer.
If instead consistent behavior is specified, then application authors
will see bad behavior even on the desktop when they are doing things
wrong (i.e., random flashing of the app if they are reading the WebGL
rendering results after they have been consumed by the compositor),
and they will change their apps in such a way to work properly on
mobile implementations as well.
You are currently subscribed to firstname.lastname@example.org.
To unsubscribe, send an email to email@example.com with
the following command in the body of your email: