What happened:
The excessive `onSpriteLoaded()` notifications were caused by the trick inside `OnlineFileRequest::completed()` implemenation,
which causes receving of two file source updates pointing to the *same* data in case the network response is `notModified` and
the local storage has the sprite sheet already stored inside.
In the SpriteLoader` implementation, it resulted in 2 extra `parseSprite()` calls and 2 extra `onSpriteLoaded()` notifications.
Then, the excessive `onSpriteLoaded()` notifications affected style images and all the unnecessarily added image dupes (btw,
the amount of these dupes `= 2 * number of style images`) were treated by the `RenderOrchestrator` as *updated* images.
Further, `RenderOrchestrator` called `ImageManager::updateImage()` for the updated images and the `ImageManager` populated the
`updatedImageVersions` map.
Finally, at every frame all the geometry tiles iterated through the `updatedImageVersions` to check whether their uploaded
textures needed patching.
All the mentioned above had a negative performance impact.
The fix:
Now, `SpriteLoader` sends `onSpriteLoaded()` notifications only if the data in the file source response is different comparing
to the existing one.
This change enables attaching images to the style with batches and
avoids massive re-allocations. Thus, it improves UI performance
especially at start-up time.
- Do not carry it over everywhere as parameter, it is a shared
instance anyway and the lifecycle is pretty much the app lifecycle
from the moment we instantiate a map.
- Rename to BackgroundScheduler because it is a Scheduler that will
do tasks in the background, we don't make assumptions if it is a
thread pool or a single thread.
- Most importantly, remove the dependency from `core` on `platform`.
* Introduce AspiringActor, EstablishedActor
This pair of objects represents the two-phase (parent-thread /
child-thread) construction that's needed to support constructing
Thread<Object> without blocking until the child thread is up and
running.
An `AspiringActor<O>` is responsible for:
- ownership of the actor's `Mailbox`
- allocating the memory for (but *not* constructing) the target object `O`
Using these two pieces--the mailbox and a stable address for `O`--an
`AspiringActor<O>` can accept messages for the target object, or provide
`ActorRef<O>`s that do so, before the object has actually been
constructed by the corresponding `EstablishedActor<O>`. (Such messages
are queued in the mailbox until after the object is constructed.)
This allows for an `AspiringActor<O>` to be created and safely used by a
thread other than the one on which the target object will (eventually)
live.
An `EstablishedActor<O>` is responsible for managing the lifetime of the
target object `O` and the open/closed state of the parent's `mailbox`.
The `O` object's lifetime is contained by that of its owning
`EstablishedActor<O>`: the `EstablishedActor` constructor executes the
`O` constructor via "placement new", constructing it at the address
provided by the parent `AspiringActor`, and the `~EstablishedActor`
destructor similarly executes the `~O` destructor (after closing the
mailbox). `EstablishedActor` should therefore live entirely on the
thread intended to own `O`.
* Remove Actor#{invoke,ask}
