- Platform-specific LocalGlyphRasterizer is responsible for deciding which glyphs to rasterize locally and for implementing the rasterization.
- Default platform implementation doesn't locally generate any glyphs -> no behavior change
- Unit test uses StubLocalGlyphRasterizer, which returns a single fixed bitmap for all CJK glyphs
- Rename glyph_loader.test to glyph_manager.test
Because a message we queue from the foreground may cause the background to complete, exit, and tear down the AsyncTask, we have to block queue processing until we've finished our call to AsyncTask::send().
Broadening the scope of a mutex is scary, but I audited the code of our four implementations of AsyncTask and I don't see any way this could cause a deadlock.
Enables -fvisibility=hidden for iOS and Linux, and adds a workaround for GCC 6.3-7.1
Adds a GCC 6 build
Enables diagnostics for C files
Fixes a shadow warning in parsedate.c
Because a message we queue from the foreground may cause the background to complete, exit, and tear down the AsyncTask, we have to block queue processing until we've finished our call to AsyncTask::send().
Broadening the scope of a mutex is scary, but I audited the code of our four implementations of AsyncTask and I don't see any way this could cause a deadlock.
Updated comment to reflect that MapView's lifecycle callback in a fragment should be called from onDestroyView rather than on onDestroy. This is consistent with that MapFragment is doing.
* [android] - downgrade minimum sdk version to 14
* [android] bump MAS version to the one which includes min sdk version 14
* bump lost version to 3.0.4
* [android] fix map snapshotter marker example
The reference to the MapSnapshotter needs to be held for the duration of the snapshot, otherwise it might be GC'd
* [android] MapRendererRunnable - avoid weak reference table overflow
Apparently on some devices the weak reference table is limited (numbers around 52000). Even though we don't use that many weak references, when GC is not called for a while they can stack up and a crash will occur before the GC has had the time to clear the references. The C++ peer now holds on to a global ref (strong) which can be obtained to queue the java peer and then release automatically so that the GC can take over after the runnable has been executed.
Apparently on some devices the weak reference table is limited (numbers around 52000). Even though we don't use that many weak references, when GC is not called for a while they can stack up and a crash will occur before the GC has had the time to clear the references. The C++ peer now holds on to a global ref (strong) which can be obtained to queue the java peer and then release automatically so that the GC can take over after the runnable has been executed.
