[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 <email@example.com>
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
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
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
3. The context may now use NPOT features.
People are objecting exactly what you just proposed. It's never a plan to incorporate NPOT into core webgl 1.0.
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
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
matrixes for web APIs). Forcing everyone to limit themselves to
mobile capabilities by artificially limiting the API can only
On Thu, Nov 17, 2011 at 5:05 PM, Won Chun <firstname.lastname@example.org>
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
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
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
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.