[Public WebGL] In defense of older hardware
Fri Jan 15 11:21:15 PST 2010
I disagree, and I'm a big fan of older 3D hardware (think SGI).
The problem is a scoping issue. WebGL supposed to be an adaptation of OpenGL
ES 2.0, so rather than thinking of it as "WebGL," think of it like OpenGL ES
2.0 by another name. If you consider that, then you'd find that any device
that cannot do OpenGL ES 2.0 doesn't really make much sense as a WebGL
And in defense of OpenGL ES 2.0 / WebGL, it is very flexible and yet
minimalistic, dropping all of the baggage that would be duplicated features
between fixed function and programmable pipelines, and required buffered
data, which has enforced more thought into how people store their data. Not
too bad an idea.
It just isn't within the scope of the WebGL spec to handle any generic piece
of hardware that can do perspective correct texture mapping. You're looking
for OpenGL 1.1+, which no spec. has been written for the Web. You'll have to
be content running native code, or drafting a different GL standard that
matches OpenGL 1.1+.
On Fri, Jan 15, 2010 at 1:42 AM, stephen white <[email protected]> wrote:
> First, I must confess that I am one of the affected. So when I mention the
> 50 million iPhones, you know I really mean me. :)
> So, not only is my older iPhone (and those 50 million other people!) not
> able to handle OpenGL ES 2.0... I'm also the owner of the 17" Macbook Pro
> with the ATI Radeon chipset that features in cmarrin's earlier discourse.
> And boy, do those demos reaaaaaallllly run slow, looking like they're worse
> than Flash and making the initial impression rather poor.
> My hardware ain't that old, and much more importantly, my hardware ain't
> that bad. I know that it can easily whap some puppies on the sides of a cube
> and spin it around. Yet the demo runs at 8fps and 110% CPU because the puppy
> pictures are 400x400 instead of 512x512. Perhaps there should not be any
> software fallback? If the hardware can't do it, just state "your hardware
> can't do it" instead of having a misleading impression? The more important
> point is that WebGL is blindingly fast when it works, and software fallback
> will lead many people (who own older hardware) to think that WebGL is like a
> really bad version of Flash.
> Onto the next point... WebGL is going to be developed over time, and these
> OpenGL ES 2.0 features that are modern now will be deprecated at some time
> in the future. There is quite a lot of older hardware, so how about having a
> deprecated API for WebGL for the older hardware now?
> 50 million iPhone users will notice! And just think about all those Macbook
> Pro laptop owners with ATI chipsets! Not to mention those older PowerPC
> So, older hardware. Deprecated branch. I know this has been talked about
> before, but I'd like to raise a point. In the Flash 3d world, the vast
> majority of processing time is spent on making affine transforms into
> perspective transforms. This is done for free by the OpenGL hardware. So
> rather than the complete and exact accurate emulation of the OpenGL fixed
> pipeline with the megashader implications of various combinations, it really
> would be good enough to have a "depth buffer and 1 light and that's all
> you're getting" option for the older hardware.
> Anything at all, really! Just being able to display some stuff in 3d, with
> perspective texturing in hardware, is better than what Flash can do. Any
> shaders that will display anything on the screen will be enough and
> sufficient and deprecated anyway. It really has to have something to handle
> NPOT textures, just as the future branch of WebGL will have to handle the
> deprecated OpenGL ES 2.0 stuff.
> 50 million (and one) people out there! Let's make them happy! Yes! Rah!
> Rah! :) And yes, I know that it will mean having calls like
> gl.bindTexture(GL_TEXTURE_RECTANGLE_EXT, m_texture); in the public API, but
> better to tackle the obsolescence problem as part of the initial launch
> since you're going to be handling it in future releases anyway. And did I
> mention 50 million (and one) people? :)
> [email protected]
> You are currently subscribe to [email protected]
> To unsubscribe, send an email to [email protected] with
> the following command in the body of your email:
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the public_webgl