- From: Dominic Mazzoni <dmazzoni@google.com>
- Date: Wed, 13 Apr 2016 15:48:18 +0000
- To: Justin Novosad <junov@google.com>
- Cc: public-canvas-api@w3.org, Frank.Olivier@microsoft.com
- Message-ID: <CAFz-FYzq6PA1iyyEMt+hxgada2yObH0JbUkeCs8F8-_gi78Xvg@mail.gmail.com>
On Tue, Apr 12, 2016 at 6:39 PM Justin Novosad <junov@google.com> wrote: > On Apr 12, 2016 7:20 PM, "Dominic Mazzoni" <dmazzoni@google.com> wrote: > > > > What's the equivalent of a path in WebGL? Is that even a concept that > exists now or is it something we'd have to define? > > The Path2D interface could be used with WebGL, but it is not ideal since > it restricts the definition of a region to a planar geometry. It would > probably make more sense to have some sort of 3D mesh primitive to get hit > regions that map more directly to elements in a WebGL scene. > I guess my question is, would a significant fraction of WebGL apps benefit from an API like this? Some examples of where I'm skeptical: * Some apps use large 3-D libraries on top of WebGL. Those libraries probably already implement hit testing, and trying to extract the right 3-D mesh and transformation matrix would be more work than just using the existing function. * Any complex 3-D scenes with obscured objects would need to expose nearly everything in the scene in order for hit testing to work correctly, and I'm afraid it would hurt performance to try to extract all of that information and do hit testing on the cpu instead of on the gpu. The 2D canvas context is a relatively high-level graphics API and it's natural for authors to already have paths representing objects, so adding hit testing is a natural extension of the straightforward use of this API. I'm just not sure that's true for WebGL. - Dominic
Received on Wednesday, 13 April 2016 15:48:56 UTC