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

Re: [Public WebGL] WEBKIT_ extensions




On 03/11/11 07:39 PM, Daniel Koch wrote:
Why is it utter madness? This frequently happens on OpenGL implementations.
You can get Apple implementations with NV and ATI/AMD extensions (1)
You can get AMD implementations with IBM, NV, SGIS, SUN extensions (2)
You can get NVIDIA implemenations with ATI, S3, IBM, SGIS, SUN extension (3)
You can get Intel implementations with IBM, SGIS, 3DFX, NV, ATI
extensions (4)

So far the world hasn't imploded..

Exactly: that's why WebGL extensions are a gray area, and why we've had a hard time making up our minds on this at Mozilla:


- on the one hand, as James mentions, in DOM APIs and in CSS one shouldn't use another vendor's prefix.

- on the other hand, as Daniel mentions, for OpenGL extensions it's commonplace.

Churn around this has a cost: the tests would need to be updated to handle multiple extension names, etc.

To resolve this once and for all, I propose that we introduce immediately WEBGL_EXT_lose_context, without waiting for the next conference call. Any objections?

Cheers,
Benoit



(1) http://developer.apple.com/graphicsimaging/opengl/capabilities/index.html (2) http://www.geeks3d.com/20111018/amd-catalyst-11-10-version-3-preview-driver/ (3) http://www.geeks3d.com/20110808/nvidia-r280-28-opengl-4-2-support-and-14-new-opengl-extensions/ (4) http://www.geeks3d.com/20110914/quick-test-intel-gma-driver-8-15-10-2509-opengl-extensions/

/Daniel/

On 2011-11-03, at 7:20 PM, James Robinson wrote:



On Thu, Nov 3, 2011 at 12:56 PM, Benoit Jacob <bjacob@mozilla.com
<mailto:bjacob@mozilla.com>> wrote:


I would like this to be discussed in the next conference call: are there any objections to renaming/cloning WEBKIT_lose_context as WEBGL_EXT_lose_context ?

    It now seems that we're going to keep the WEBKIT_lose_context name
    in the interim.


Mozilla should not ship anything with a WEBKIT prefix. If you want to ship something with a vendor-specific prefix use your own vendor name, not someone else's. That way lies utter madness.

- James



    Benoit


On 01/11/11 10:18 PM, Mark Callow wrote:

        For the other APIs the convention is to use EXT for
        multi-vendor but not
        Khronos ratified extensions. That would seem to be appropriate
        here too.
        It is nuts to have different names for the same extension in
        different
        browsers.

        So the name of the extension would be EXT_lose_context. The
        name string
        for enabling it would be WEBGL_EXT_lose_context as extensions
        always
        start with the API name.

        Regards

        -Mark



        On 02/11/2011 02:51, Benoit Jacob wrote:


On 01/11/11 01:41 PM, Adrienne Walker wrote:

                El día 31 de octubre de 2011 14:53, Benoit
                Jacob<bjacob@mozilla.com <mailto:bjacob@mozilla.com>>
                escribió:


In the case of WEBKIT_lose_context, since it is so simple and useful for all browsers, I would really like it to become WEBGL_lose_context. Does anybody object to that and what steps need to be taken to make that happen?


There was some previous discussion about this here: http://www.khronos.org/webgl/__public-mailing-list/archives/__1012/threads.html#00092 <http://www.khronos.org/webgl/public-mailing-list/archives/1012/threads.html#00092>


At the time, there were reservations about adding the WEBGL tag without more general approval or ratification from Khronos.


Thanks, I didn't remember this conversation. Since it seems to have been such a large debate, for now we will just rename it to MOZ_lose_context on our side until consensus for WEBGL_lose_context happens.

            Can I go ahead and add MOZ_lose_context to the registry?

            I disagree with the arguments that WEBGL_lose_context is
            not needed as
            it could be implemented in pure JavaScript. A big focus at
            the moment
            is to get Web developers to care about
            contextlost/contextrestored
            events. It would help if we could just point them to a
            WEBGL_lose_context extension to test their app's behavior
            in all
            supporting browsers, rather than having to use a shim for
            all WebGL
            entry points.

            Cheers,
            Benoit



                -enne



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



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



--- Daniel Koch -+- daniel@transgaming.com <mailto:daniel@transgaming.com> Senior Graphics Architect -+- TransGaming Inc. -+- www.transgaming.com <http://www.transgaming.com/>



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