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

Re: [Public WebGL] Proposal of OES_texture_npot extension



IIRC the main concern originally was that while support is pretty much ubiquitous on desktop (and has been for some time), it's not widely supported on mobile, and the intent was to prevent authors accidentally writing WebGL apps on desktop that won't port to mobile. I think an extension that you must request before the feature is enabled solves this problem (since it obligates a not-supported code path), but I think at the time the priority was to have everything universally supported, especially while WebGL was new.

NPOT support comes as core in OpenGL ES 3 as I understand it, and I'd be happy to wait for the next WebGL based on ES 3 instead of specifying an NPOT extension now.

Ashley



On 2 July 2013 10:24, Karol Swiniarski <k.swiniarsk2@samsung.com> wrote:

I would like to bring back the topic of handling NPOT textures extension.
Last discussion in this matter was almost two years ago.
https://www.khronos.org/webgl/public-mailing-list/archives/1111/msg00080.htm
l
Conclusion was, that hardly no hardware was capable of handling it
correctly, so presenting such extension would cause much fragmentation.
Nowadays more and more hardware is capable of handling NPOTs correctly and
efficiently.
However, current specification forces frameworks (for example WebKit) to
emulate improper behavior (substitution of original npot texture witch black
texture) and simulate WebGL error.
What's the current opinion on proposing OES_texture_npot for WebGL
(preferably same way as for OpenGL ES)?



-----------------------------------------------------------
You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email:
unsubscribe public_webgl
-----------------------------------------------------------