Is it time to remove the compatibility cruft?

[UPDATE 23 August 2010: one of the API changes this post is talking about, from CanvasFloatArray to WebGLFloatArray, was itself superseded by a change to Float32Array later on. The test page here is no longer relevant -- it will fail saying that it can't find the canvas array types]

[This is a cross-post from the WebGL forums.]

A lot of current WebGL pages, including the ones on this site, have code to handle old compatibility problems between the browsers; in particular, I always check for the old context names, the CanvasFloatArray/WebGLFloatArray move, and the move from getShaderi to getShaderParameter.

It looks like these checks might now be unnecessary; checking Firefox and the Chrome dev channel, it looks like both of them use the current spec for all three of these. In general, Safari seems to be ahead of the others when it comes to spec compliance, so it’s *probably* sorted too…

However, I’ve only checked on a PC, and it would be really interesting to hear what everyone else sees — in particular people using Macs and Linux. I’ve put together a page that checks browsers for the three changes above; test results would be much appreciated!

To check your browser, go to this page. Copy and paste the results, and put them in a comment here along with your OS and browser details. I’ll post with the aggregated results in a day or so.

Thanks!

You can leave a response, or trackback from your own site.

12 Responses to “Is it time to remove the compatibility cruft?”

  1. Paul Brunt says:

    It all looks okay on latest FF and Chrome under Linux.

    chome:
    Checking WebGL… array types vs Canvas… array types: OK (found WebGLFloatArray)
    Checking context name: OK (got using experimental-webgl)
    Checking parameter getter functions: OK

    FF:
    Checking WebGL… array types vs Canvas… array types: OK (found WebGLFloatArray)
    Checking context name: OK (got using experimental-webgl)
    Checking parameter getter functions: OK

  2. Apostolos Tsakpinis says:

    Webkit Nightly:
    Checking WebGL… array types vs Canvas… array types: OK (found WebGLFloatArray)
    Checking context name: OK (got using experimental-webgl)
    Checking parameter getter functions: OK

    Chromium Mac Nightly:
    Checking WebGL… array types vs Canvas… array types: OK (found WebGLFloatArray)
    Checking context name: Failed (couldn’t get using any name I know about)

  3. FF nightly on Mac:
    * Checking WebGL… array types vs Canvas… array types: OK (found WebGLFloatArray)
    * Checking context name: OK (got using experimental-webgl)
    * Checking parameter getter functions: OK

  4. gero3 says:

    Some people will still not be able to get OKs verywhere becuase chromium doesn’t update automatically.

  5. giles says:

    @Paul, @Apostolos, @David — thanks for the data!

    @gero3 — you’re quite right, but that will give us an idea of how many people are using non-updated versions of Chromium, which is useful information in itself.

  6. HannesB says:

    Everything OK with FF and Chromium nightly on Linux 64bit

  7. giles says:

    Excellent — thanks, HannesB!

  8. gero3 says:

    I needed to update chromium. I had forgotten to add it previously.

    Checking WebGL… array types vs Canvas… array types: OK (found WebGLFloatArray)
    Checking context name: OK (got using experimental-webgl)
    Checking parameter getter functions: OK

  9. jcongote says:

    Minefield (Mozilla nightly ) – MAC

    Checking WebGL… array types vs Canvas… array types: OK (found WebGLFloatArray)
    Checking context name: OK (got using experimental-webgl)
    Checking parameter getter functions: OK

    WebKit – MAC

    Checking WebGL… array types vs Canvas… array types: OK (found WebGLFloatArray)
    Checking context name: OK (got using experimental-webgl)
    Checking parameter getter functions: OK

  10. giles says:

    Brilliant, thanks everyone! Looks like we can get rid of the cruft, everything seems to be using the new APIs.

  11. Ivan says:

    Could not find Canvas array types for WebGL

  12. giles says:

    Yup, that’s expected behaviour nowadays.

Leave a Reply

Subscribe to RSS Feed Follow Learning WebGL on Twitter