On Mon, Jan 4, 2016 at 4:46 PM, Robert O'Callahan <[email protected]> wrote: > On Tue, Jan 5, 2016 at 10:46 AM, Kearwood "Kip" Gilbert < > [email protected]> wrote: > >> In WebVR, we often present UI as a Head's Up Display (HUD) that floats >> in front of the user. Additionally, we often wish to show 2d graphics, >> video, and CSS animations as a texture in 3d scenes. Creating these >> textures is something that CSS and HTML are great at. >> >> Unfortunately, I am not aware of an easy and efficient way to capture an >> animated of an interactive HTML Element and bring it into the WebGL >> context. A "moz-element" -like API would be useful here. >> >> Perhaps we could solve this by implementing and extending the proposed >> WEBGL_dynamic_texture extension: >> >> >> https://www.khronos.org/registry/webgl/extensions/proposals/WEBGL_dynamic_texture/ > > > This proposal seems unnecessarily complex. Is there a way for me to send > feedback?
Yeah, we have a public mailing list: [email protected] As with anything WebGL related, you can also just talk to me about it. > > Essentially, we would extend the same API but allow the WDTStream >> interface to apply to more HTML elements, not just HTMLCanvasElement, >> HTMLImageElement, or HTMLVideoElement. >> >> We would also need to implement WEBGL_security_sensitive_resources to >> enforce the security model: >> >> >> https://www.khronos.org/registry/webgl/extensions/WEBGL_security_sensitive_resources/ > > > I wish I'd known about this proposal earlier! This looks pretty good, > though I'd always thought this would be too complicated to spec and > implement to be practical. Glad to be wrong! Although I think we should get > as much feedback as possible on this in case of hidden gotchas. Historically in our investigations of this, it seemed very very hard to guarantee a lack of timing vectors, even just for arithmetic. (Particularly since we're handing the sources to the driver, which will try to optimize away as much as it can) > > Does this sound like a good idea? I feel that this is something that >> all WebGL developers would want, as it would make building front-ends >> > for games much easier. >> > > Yes, I think together these would be very useful. It only helps some games. Most game development efforts will likely be unaffected, since it's generally easiest to use an existing engine, which will already have such things handled. Most games will either just use overlayed HTML, or have an in-engine solution for UI. The desire to embed web elements in a scene itself is relatively rare. (Certainly few existing games do this) > > If others feel the same, I would also like to follow up with a proposal >> to make the captured HTML elements interactive through use of an >> explicit "pick buffer" added to canvases. >> > > How would that work? Being able to synthesize mouse (touch?) events in HTML > elements would add another set of issues. > > I assume the idea of mixing CSS 3D-transformed elements into a WebGL scene > has been rejected for some reason? This can't reasonably be done given the level of abstraction provided by GL APIs. _______________________________________________ dev-platform mailing list [email protected] https://lists.mozilla.org/listinfo/dev-platform
