[Public WebGL] WebVulkan and multithreaded command queue assembly

Ashley Gullen [email protected]
Wed Mar 4 09:06:34 PST 2015

The impression I get is that web workers are already the web's model for
threads and that seems unlikely to change. Canvas rendering from workers
already aims to lift draw call generation off the main thread. I would
guess getting the browser to manage the thread safety of canvas proxy draw
calls is much more practical than making the entire JS engine thread-safe.
I would think the most likely direction to go in is canvas rendering from
*multiple* workers - but how that works, or if it would even be useful,
probably needs to wait until there is at least a draft Vulkan spec!


On 4 March 2015 at 16:18, Florian Bösch <[email protected]> wrote:

> On Wed, Mar 4, 2015 at 5:09 PM, Brandon Jones <[email protected]> wrote:
>> mapBuffer in WebGL2
> That's quite a bummer.
>> That's not to say that we shouldn't look to this new wave of APIs for
>> inspiration. I think there's several concepts present across all of the new
>> APIs that would play well on the Web, and may even work nicely with web
>> workers in some form. I just don't don't believe we'll get a ~1:1 mapping
>> like we saw with WebGL and OpenGL ES.
> Well since Vulkan is the eventual future, I don't think it's sustainable
> to have a bifurcation of Web Hardware Accelerated something APIs with
> different semantics than native APIs. You'll lose out on:
> - existing experience
> - cross compilation
> - tooling
> - documentation
> - books
> That could easily break the back of any attempt to do so.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20150304/26bd5084/attachment.html>

More information about the public_webgl mailing list