[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 3:56 PM, Ashley Gullen <ashley@scirra.com> wrote:
There's a wider debate going on I don't feel I can comment on, but I do think the NPOT extension in particular is a simple case.  It only needs to relax two rules:
1. generateMipmap(TEXTURE_2D) will succeed even if the texture is NPOT.
2. The REPEAT wrap mode may be used on NPOT textures.
If the concern is this causes developers to assume the presence of NPOT, then in the spirit of "make it hard to accidentally use optional capabilities", how about something like this?

1. Require that the context by default act as if there is no NPOT support.
2. If context.getExtension("...texture_non_power_of_two") is called, and the extension is supported, enable NPOT support.  I suppose the function does not need to return anything, or could return an empty interface.
3. The context may now use NPOT features.

This way nobody can accidentally use either of the NPOT features without explicitly requesting it first.  If someone makes that call, presumably they know the workarounds, and this should prevent accidental incompatibilities.  Mobile support may be limited, but then the only side effect is a slight degradation in visual quality, and I suppose mobile hardware might eventually catch up anyway.  Desktops are still a big chunk of WebGL's use, and it does seem to me to be a particularly low-risk extension that also helps significantly improve the visual quality of 2D games in WebGL, and we think that's an important use case because our benchmarks show 2D in WebGL running about 3x faster than hardware accelerated 2D contexts.

Could you look at my reply earlier in the thread? If the NPOT extension could only expose that functionality supported on existing mobile hardware, that seems like a good alternative, assuming that that subset of OES_texture_npot suits your needs.

-Ken

 

Ashley Gullen
Scirra.com

On 17/11/2011 22:48, Glenn Maynard wrote:
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