I believe what to expect is to load a SVG source as a Blob in worker, and do createImageBitmap from a worker.

I tried it, and it seems that our ImageDecoder cannot decode a SVG.

noel@: is it correct that our decoder cannot handle the decoding of a SVG resource? Do we have a plan on this?

FWIW I just filed https://bugs.chromium.org/p/chromium/issues/detail?id=606319 for blob decoding. Apologies if these are essentially dupes.

Issue 606319 has been merged into this issue.

http://jsbin.com/mitege/edit?js,console - demo of blob decoding failing from a window.
http://jsbin.com/wipaxoh/edit?js,console - demo of blob decoding failing from a worker.

This is highly non-trivial since it involves creating an SVG DOM off the main thread, which has never been done in Blink. Even though the SVG DOM would be isolated (no script access, and no interactions with CSS), there may be concurrency issues in the code.

@pdr, @davve: WDYT?

Marking this as a feature request.

Since the SVG engine is so tightly coupled with the rest of core/ the only reasonable thing to me would be to spin up a renderer process in this case (or use a separate, minimal renderer). Some of the issues might be shared with supporting SVG in favicons: https://bugs.chromium.org/p/chromium/issues/detail?id=294179

For what it's worth, the main reason I'd want to use a worker here is to render the SVG off the main thread, so if createImageBitmap just did that (https://bugs.chromium.org/p/chromium/issues/detail?id=580202) having this happen in a worker becomes a lot less interesting.

jaffathecake@: createImageBitmap(blob) already does image-decoding on a background thread.

Whoa, then is https://bugs.chromium.org/p/chromium/issues/detail?id=580202 redundant?

This might be a good opportunity to at least look at how hard spinning up a renderer would be. There are several usecases where we've wanted to do this in the past for SVG (svg favicons, svg in the browser ui, svg cursors, etc).

Do you have a feel for the performance of spinning up a renderer? I can't think of any concurrency issues we'd hit with this approach, beyond what an OOPIF with SVG in it would cause.

Is https://bugs.chromium.org/p/chromium/issues/detail?id=606319 definitely a dupe? It refers to createImageBitmap(blob) working for SVG, whereas this issue is specifically about createImageBitmap(svgBlob) working within workers.

Yep, not a duplicate. Thanks for pointing out the mistake.

Any progress here or plans for progress? With OffscreenCanvas almost ready this in addition would make it so rendering an SVG and getting ImageData could be entirely done in a worker, which would remove a major bottleneck on the main thread in a project I have.

@12 makes it sound like SVG rendering is already mostly isolated enough that this should be feasible.

OffscreenCanvas is shipping in Chrome 69, but there doesn't appear to be any way to render an SVG to an OffscreenCanvas in a worker due to this issue. This will be a hurdle to adopting OffscreenCanvas for any use cases that render SVG to a canvas. Any chance this could be worked on now that OffscreenCanvas is shipping?

The workaround is probably to do something like post to the main thread to do createImageBitmap with the SVG and then post the resulting ImageBitmap back to the worker.

We've tried to work on this in the past. It's very hard to do and it goings a bit against the spirit of OffscreenCanvas on Workers, since we will need to be blocked on the main thread anyway to do the work.

Since there's a workaround that is almost as fast as we can achieve internally, I'd argue we should drop this, unless there's a clear path to eventually be able to render SVG from Workers.