W3C home > Mailing lists > Public > public-canvas-api@w3.org > April to June 2016

Re: Hit regions and WebGL...

From: Dominic Mazzoni <dmazzoni@google.com>
Date: Wed, 13 Apr 2016 15:48:18 +0000
Message-ID: <CAFz-FYzq6PA1iyyEMt+hxgada2yObH0JbUkeCs8F8-_gi78Xvg@mail.gmail.com>
To: Justin Novosad <junov@google.com>
Cc: public-canvas-api@w3.org, Frank.Olivier@microsoft.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

This archive was generated by hypermail 2.3.1 : Wednesday, 13 April 2016 15:48:56 UTC