On 2012-01-25, at 11:35 AM, Marco Di Benedetto wrote:
please correct me if i'm wrong.
as far as i understood from this discussion:
1) ANGLE is not able to handle depth cube maps (because of D3D9 restrictions).
It's not only ANGLE/D3D9. OpenGL 2.1 doesn't support depth cube textures either. This was only introduced to Desktop OpenGL with 3.0.
2) to overcome this, a "branch" of OES_depth_texture (namely WEBGL_depth_texture) that is basically the same but without support to depth cube maps is being proposed.
3) almost all ES 2.0 implementations (mobile etc.) expose OES_depth_texture, so (if they passed the conformance tests, as i hope) they can handle depth cube maps.
It's actually not that simple. It turns out the OES_packed_depth_stencil extension contradicts OES_depth_stencil and says that depth cube textures are *not* supported. I think more testing will need to be done on ES2 platforms to determine how prevalent depth cube texture support actually is and it certainly seems prudent to assume a more limited form of the extension, if nothing else so that it can be supported on GL 2.1 and D3D9.
why give priority in the extension registry update to WEBGL_depth_texture rather than OES_depth_texture?
i mean, isn't the "create a specifications that runs on most platform as possible, using the lowest specs as possible, even if they use an emulator (ANGLE) that cannot handle all the specs" plilosophy starting to scrape the specifications a bit too hard?
we already lost the early support for lot of functionalities just because they are not available to all implementations. ok, that's fine (well, not ok for me, but i understand the valid point). "in the future", when developers that clearly do not come from the opengl community and have to be trained when using webgl, these restrictions will be relaxed and extensions will be ratified even if they don't have a wide support. ok.
but giving priority to the ANGLE version of the extension because an emulator (ANGLE) cannot cope with the original specs, seems too much for me.
i'd be far more happy if the OES extension would pop up in the registry before the ANGLE one.
Would you still be happy if the OES extension was present but not widely supported?
ISTM that making 2 extensions with explicitly identified functionality is better than having one which is unclear.
again, please correct me if i'm wrong or i lost something in the discussion.
(p.s.: please don't misunderstood me, ANGLE is great.)
On 25/01/2012 16:55, Florian Bösch wrote:
Changed the draft to the prefix WEBGL, excluded cube depth maps, added the IDL and defined the error in case of attempted cube depth map usage, draft is attached (webgl_depth_texture.tar.bz2)