[Public WebGL] GL_OES_element_index_uint

[email protected] [email protected]
Fri Feb 11 05:54:10 PST 2011

My experience with an actual full-on WebGL game "in the wild" for over a
month is that it's not the presence or absence of extensions that is the
problem for portability.  Even sneaky "pseudo-extensions" - like the
feature that requires implementations to support some arbitrary number of
vertex textures...but allows that number to be zero(!)...are manageable
providing your read the spec carefully enough!

You can work around those things because you can test for them unambiguously.

My problems have mostly been with two things you can't test for:

1) Cases where some feature isn't supported in hardware - so the driver
does a software fallback.  This has been the bane of OpenGL developers
from day #1 - WebGL makes it even tougher.  One old laptop we have at home
reports that it DOES support vertex texturing - but when you try to use
it, your frame rate drops by a factor of 20!  Presumably it's dropping
back to running the vertex shader in the CPU...badly!  The pain is that I
can't test for that cleanly.  If the driver just came out and honestly
told me that it didn't support vertex textures - then I have an acceptable
fallback available...but if it claims to have it, but doesn't really do it
in any kind of useful way - then that completely blows away my ability to
fall back intelligently.  Direct3D-based systems quite often do this in
order to meet Microsoft's minimum feature requirements for Windows
Vista/Windows 7 - but it's a pain in the butt!

2) Shader limitations - where I'd get some complicated shader working,
test it on a bunch of machines with no problems - then find some specific
system that would just fail to compile it...sometimes with no useful error
message.  If I have access to that particular hardware/browser/OS combo
then I can generally fix it by playing around and making a simpler version
of the shader with less and less features until it runs.  But it's a
hit-and-miss kind of thing...just how simple does it have to be to run on
every single GPU on the planet?  There is literally no way to know other
than to try it on a bazillion machines.

For small developers, getting access to that huge variety of systems to
find these kinks is really tough.  Between work, family and friends - I
can reach maybe a dozen qualitatively different machines (I have 8
computers at home!).  But when your web site is accessed by the general
public, there are VASTLY more kinds of system than that out there.  Most
of the time, the best you get is an email from some end user who says "It
didn't work" - with very little other information ("It's a Dell"...like
that helps!).

I **REALLY** think Firefox should rethink their policy of hiding the
VENDOR/DRIVER/etc data.  It completely sucks...and makes producing a
quality product on Firefox almost impossible...as I predicted it would.

I need for my application to report back to the server when it fails to do
something like compiling a shader - or when it fails to run efficiently -
so I can log the error message and the type of system it was running on
*accurately*.  Then I have some kind of chance to fix problems...rather
have than a bunch of pissed-off users who (in this world of social media)
are only too happy to spread the news of how badly my website sucks!  Bad
news travels faster than good.

  -- Steve

> On Thu, Feb 10, 2011 at 3:57 PM, Jonathan Feldstein <[email protected]>
> wrote:
>> Hi Ken,
>> Thanks for the quick reply. I guess I'm a touch confused. Doesn't the
>> whole extension concept imply that not everyone needs to implement them?
>> Case and point you just mentioned that this extension is supported by
>> Google but not Apple on the iPhone and iPad platforms for OpenGL ES 2.0.
> While that is true, there's a strong desire in the WebGL working group
> to avoid fragmenting the developer landscape by adding official
> extensions (such as those adopted from the OES namespace) that are
> unsupported on a large class of hardware.
> A vendor would be more than welcome to add an extension to their WebGL
> implementation (RIM_element_index_uint?) and try to garner support for
> other vendors to implement it as well.
> -Ken
>> All the best,
>> - Jonathan Feldstein
>> -----Original Message-----
>> From: Kenneth Russell [mailto:[email protected]]
>> Sent: Thursday, February 10, 2011 6:36 PM
>> To: Jonathan Feldstein
>> Cc: [email protected]
>> Subject: Re: [Public WebGL] GL_OES_element_index_uint
>> On Thu, Feb 10, 2011 at 2:52 PM, Jonathan Feldstein <[email protected]>
>> wrote:
>>> After playing around with WebGL one thing that I noticed was that the
>>> specification seems to be missing the ability to create 32-bit index
>>> buffers. OpenGL ES 2.0 has the ability to enable this with the:
>>> GL_OES_element_index_uint extension.
>>> 65536 possible index values doesn't really seem like enough values for
>>> today's games. People will be forced to split their index values into
>>> multiple arrays of data. Would it be possible to add this extension, or
>>> is
>>> there a good reason that it is currently absent?
>> I don't think the WebGL working group has discussed this extension.
>> However, after doing some searching, it looks like while Android
>> hardware has widespread support for it, it isn't supported on any
>> current iOS hardware, iPhone or iPad. We want WebGL content to run
>> identically across desktop and mobile hardware, so in my opinion the
>> lack of support on iOS makes adding it to the WebGL extension registry
>> a non-starter.
>> -Ken
>> ---------------------------------------------------------------------
>> This transmission (including any attachments) may contain confidential
>> information, privileged material (including material protected by the
>> solicitor-client or other applicable privileges), or constitute
>> non-public information. Any use of this information by anyone other than
>> the intended recipient is prohibited. If you have received this
>> transmission in error, please immediately reply to the sender and delete
>> this information from your system. Use, dissemination, distribution, or
>> reproduction of this transmission by unintended recipients is not
>> authorized and may be unlawful.
> -----------------------------------------------------------
> You are currently subscribed to [email protected]
> To unsubscribe, send an email to [email protected] with
> the following command in the body of your email:
> unsubscribe public_webgl
> -----------------------------------------------------------

You are currently subscribed to [email protected]
To unsubscribe, send an email to [email protected] with
the following command in the body of your email:
unsubscribe public_webgl

More information about the public_webgl mailing list