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

Re: [Public WebGL] GL_OES_element_index_uint



On Fri, Feb 11, 2011 at 5:54 AM,  <steve@sjbaker.org> wrote:
>
> 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!).

If they use chrome, you can ask them to type in about:gpu and copy the
information there back to you.  That page already has a bunch of
information there, and probably will have more soon.  That page helps
a lot for the Chrome GPU team.

>
> 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 <jfeldstein@rim.com>
>> 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:kbr@google.com]
>>> Sent: Thursday, February 10, 2011 6:36 PM
>>> To: Jonathan Feldstein
>>> Cc: public_webgl@khronos.org
>>> Subject: Re: [Public WebGL] GL_OES_element_index_uint
>>>
>>> On Thu, Feb 10, 2011 at 2:52 PM, Jonathan Feldstein <jfeldstein@rim.com>
>>> 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 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
>> -----------------------------------------------------------
>>
>>
>
>
>
> -----------------------------------------------------------
> 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
> -----------------------------------------------------------
>
>

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