jszip
jszip copied to clipboard
Stuk
Optionally use WebWorkers for decompression/compression instead of operating on the main thread.
It is currently possible to efficiently transfer ArrayBuffers to and from WebWorkers using transferables. https://developer.mozilla.org/en-US/docs/Web/API/Transferable https://developers.google.com/web/updates/2011/12/Transferable-Objects-Lightning-Fast?hl=en
In this way it might yield a responsiveness/apparent performance improvement to do compression and decompression on a separate thread. For some applications, (including my own,) this might be suitable.
Why not implement that feature on top of this library rather than conflating features?
In other words if you want to unzip in a worker then use this library in your own worker. no need for this library to get more complicated.
Fair enough. I was considering doing that but wasn't sure if maybe it would be something mainline would be interested in integrating.
The main issue I see is to locate JSZip's script. The code can be included with a <script> tag, included with a loader (requirejs for example), bundled with other dependencies (r.js, browserify, webpack), etc. It can also be a direct dependency or a transitive dependency (with any combination of ways to include js code).
We could add methods to let the user setup everything and internally match the message passing API of web workers if available, but I think it would more fit an separate project.
For now, using self.importScripts('path/to/jszip.js'); in the web worker should be the easiest way.
I'm working on a project right now where want to use jszip using WebWorkers. @pkovac, did you end up unzipping in a worker? Anything I should be aware of before I go down that route?
It's been a while since I worked on it, but looking at the history I don't think I ever did implement it. My project managed to scavenge startup time savings elsewhere.
@pkovac thanks for the response. I went down this path a little bit, but there's a few explicit calls in the library to the window object, which returned an error, of course. So I'm checking out zip.js, which is unfortunately doesn't seem as active as this project but does use WebWorkers by default.
Seems fixable though. Even if they aren't interested in adding webworkers directly, removing the window object references might be worthwhile.
yeah in utils.js and support.js, replacing 'window' with 'self' looks like the right fix.
Anything going on with this issue? I'd like to use jszip in my project but would prefer to use it in the worker.
I've made a PR with changes suggested by @pkovac (replacing window with self). Could a maintainer please merge it in and release a version? I'd like to avoid publishing my fork on npm/bower...
Can someone give me a code example of how I can implement web worker with JSZip. When zipping is in progress and I switch to new tab in browser zipping pauses. I get to know using web worker this issue can be resolved, but I have no idea of web workers. Please help I have to fix this issue asap.
This is kind of silly that this isn't automatically done within jszip.. This is a major performance optimization for modern browsers.