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

Re: [Public WebGL] WebGL NPOT texture support



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). 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 <wonchun@google.com> wrote:
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.

On Thu, Nov 17, 2011 at 12:44 PM, Tony Parisi <tparisi@gmail.com> wrote:
I 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...

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.

--
Glenn Maynard