This file was added 8 years ago, and currently breaks `haxe.zip.Reader` usage on all targets but Neko.
I don't see a reason why it should be kept around, so let's delete it.
Closes#1400.
It took a lot of work to get web workers to work, but web workers finally work!
`transferList` doesn't seem to work, though. It makes the object
inaccessible as expected, but it doesn't seem to affect performance.
Not well-tested yet, especially the web workers.
In addition to web workers, this completely rewrites both
`BackgroundWorker` and `ThreadPool`. It adds thread safety via the
`WorkOutput` object, adds flexibility by making `BackgroundWorker` build
off `ThreadPool`, and exposes an `eventSource` variable that tells
listeners which job dispatched a given event.
This improves the old web worker implementation by reusing the _entire_
JS file. This is slower but ensures that all classes are available,
simplifying the end user experience. Web workers are now forbidden from
using instance functions, which also simplifies things. And finally, the
code attempts to restore the prototypes of all class instances passed
across threads, though this relies on the exact way Haxe generates
JavaScript, and may not work in Haxe 3 or Haxe 5.
This actually makes `Future` more thread-safe than its parent classes.
Unfortunately `BackgroundWorker` and `ThreadPool` can't receive the same
treatment, as it'd break backward compatibility.
The `Future` constructor creates a new `Future` instance, and in other
news, this floor is made out of floor.
Since there's now so much more to read, we should cut out the blatantly
obvious parts.
Without this, if an error happened during a `ThreadPool` job, that
thread would exit without updating `currentThreads`.
This can almost replace `FutureWork`'s error handling, but not quite.
Modifying `onUpdate` is not thread safe, and must only be done on the
main thread. This is more important - and more enforceable - than most
of the "only do this on XYZ thread" comments.
With this, a library can set a "default" icon, to be used only if the
user doesn't provide a better one.
Additionally, this treats SVGs as "near" matches rather than exact,
meaning that a perfect-size PNG will take precedence over an SVG. Why
would the PNG even exist if you didn't want to use it in that one case?
And finally, I took the liberty of cleaning up `findNearestMatch()`. It
seemed unnecessarily confusing for what it did.
