[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] WebGL NPOT texture support
On Thu, Nov 17, 2011 at 2:48 PM, Glenn Maynard <firstname.lastname@example.org>
We've discussed this before, but in recap: I strongly disagree with the idea that WebGL should limit everyone to least-common-denominator hardware features. Whether to pay the cost to support mobile
hardware (in reduced capabilities and/or greater development time) should
be the developer's choice; WebGL should not force that choice on me.
Make it hard to accidentally use optional capabilities (more can be done here, as we've discussed, eg. capability profile extensions) and document which extensions are available on which platforms (like http://caniuse.com
's matrixes for web APIs).
is relatively simple. There is only 2 dimensions, browser and version
WebGL on the other hand would need 4-5 dimensions, browser, version, platform, GPU, driver
I'm not saying whether or not we should limit WebGL. I'm just pointing out it's not nearly as simple a problem as the one caniuse.com
is attempting to solve.
Forcing everyone to limit themselves to mobile capabilities by artificially limiting the API can only slow adoption.
On Thu, Nov 17, 2011 at 5:05 PM, Won Chun <email@example.com>
To the standards-minded folk: considering that WebGL has plenty of other ways a "bad first experience" might happen, something like NPOT textures that has semi-reasonable fallbacks (blurry images via rescaling is better than utter failure) would not be very high on my list. And if developers are the ones having that "bad first experience" then you'll never even have the user problem.
Blurring images by automatically resizing them (without the application asking for it) is not a reasonable fallback. If I upload a texture, and query it at some point, I should always get the same result; I should not get an averaged value. That would wreak havoc with some shaders, eg. textures which are actually tables of non-image data, such as histogram data or indexes into other textures for more complex algorithms.
Resizing images when explicitly requested is one thing, but doing it automatically should be completely prohibited.
Right: if resampling is supported, then it should be an explicit request. I don't have a strong opinion on whether it's actually worth adding or not.
On Thu, Nov 17, 2011 at 12:44 PM, Tony Parisi <firstname.lastname@example.org>
think you are suggesting, in response to my resample suggestion, that
the browsers provide functions that let developers do resampling with
high performance but under explicit developer control (i.e. enough
params so that there is no 'magic' or inconsistency). Did I get that
right? If so I like that even better...