I regenerated assets.zip so that all file paths have an `assets/` prefix, as the Android AssetFileSource implementation asserts, and removed `TEST_DATA` from the paths.
It's a premultiplied image. This implies that we were misusing encodePNG
in most cases, as we were passing premultiplied pixels which were then
interpreted as unmultiplied. I changed encodePNG to accept premultipled
pixels, and unpremultiply in the implementations.
The callback will be called when any of the resources requested
from the network failed to load.
There is not recovery implemented yet, so the closest thing to
reseting the Map object and reloading all the resources would
be setting a new style.
- static rendering now also runs in a separate thread; you have to start it with map.start(Map::Mode::Static) and join the thread with map.stop() before destructing the Map object
- map.renderStill() takes a callback with will be invoked on the *map* thread, so you'll have to figure out your own method of dispatching back to the main thread.
Thread<T> is a generic thread management object that starts a thread, creates an object T in that thread and calls its .start() function. When the Thread<T> object is destructed (which must happen in the thread that created it), it'll call the object's .stop() function, and wait for thread termination. The .stop() function must somehow get the thread to terminate. Note that object T's constructor/destructor/start()/stop() must be protected/private, and Thread<T> must be declared as a friend class. All public functions may be called from any thread and are exposed through operator->().
RunLoop encapsulates a libuv runloop and has a facility of dispatching function objects to the thread. It can be used either as a worker thread class by itself, or it can be derived from. This commit converts SQLiteCache to derive from RunLoop and removes the custom code used previously for managing the cache thread.
No initialization is needed anymore and we can use the logging functions
safely at any point of the code (threading is not handled though, so you
might get multiplexed messages if you log from two threads
simultaneously).
