[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] ETC texture compression.
On 25 August 2010 02:59, Steve Baker <firstname.lastname@example.org>
Vladimir Vukicevic wrote:
> The extensions that we're looking at are things that are defined as extensions, but generally have very wide (or universal) availability. So that argument doesn't apply there -- it's very different defining an extension for webgl for something that will be present on 95% (if not 100%) of target hardware, vs. something that is known to not be present on half or more.
> - Vlad
The trouble is that if the extension is "nearly" universal - and useful
enough to matter, many application authors are going to be tempted to
use it - and not bother to write fallbacks for it because the additional
revenue from (say) 5% of the market would not pay for the additional
development cost. Also, a lot of ground-breaking web sites are produced
by amateurs who may well find themselves unable to dig up a sufficiently
ancient machine to test on to debug all of these possibilities.
If WebGL programs don't run exactly the same everywhere, the web will
become full of apps that simply fail for ill-explained reasons on random
machines. That will reflect badly on the standard. I think we should
avoid extensions in at least the first version of WebGL for exactly that
On balance, I would prefer that we didn't ever provide extensions. I
believe that we should be aggressive about the hardware you need in
order to be able to run WebGL. If 5% of machines don't have some
important and "nearly" universal extension then let's make that a part
of the core API and declare the 5% of machines obsolete and unable to
support the API. Let's drive the community rather than lagging it.
Right now - even without extensions - we have problems. Sometimes the
underlying OpenGL will silently fall back on software emulation to
implement a feature rather than admit that the hardware can't do it -
and the result is too slow to use (Vertex textures...to pick a
particularly nasty example). The spec claims that you can use this
feature - but in practice it's not always usable - and the only way to
detect that there is a problem and provide a fall-back is to measure
in-game frame rates (which given garbage collection and the general
randomness of timing in a browser environment is tricky at best)...argh!
So the fear and assumption of that programmers will screw up extensions management is to prevent anybody from using it ?.
Extensions are just that, what the word states.
If people have modern gfx cards in their PC, they expect a certain level of graphics,
and it can for some products be worth the man hours it so implement and QA extensions to make it look better and allow for a nice user experience.
The same product can benefit from being able to run on less capable devices while still using the same development environment,
its not looking as good but it works, and users don't expect the same level of graphics - so all is fine.
Its IMO important to allow for somewhat competitive graphics by extensions to make it viable to choose the web platform as the only development target.
The alternative is to develop traditional desktop versions along with a web version, if its deemed worth the trouble that is..
Id rather handle extensions then multiple development environments / delivery platforms.
If programmers are feeling insecure about extensions, its reasonable to not use them..
Or to use a 3D engine. that's what they are for ="">
Incompetent people will find 1000 other ways to screw up, you cant prevent that.
If your trying to remove all theoretical possibilities for programmers to screw up,
you need to give them a tightly controlled and limited point and click tool and only that,
people who can handle more cant be allowed to do that, because the others will do it too and screw up , right ?.
Its a strategic business decision to design a product to transparently adapt by the discrete state machine logic that correctly extension usage is, gracefully degrade in visual quality but still work.
Its not up to you to do that decision for us by removing that option !
I think its wrong that fear and generalising assumptions where you try to quantify programmers incompetence should be what settles a new standard.
It would come with a price to do so, it hurts the adaptation by making the platform less viable then it really needs to be.