| Age | Commit message (Collapse) | Author |
|---|
|
Fixes bug #695191 - Mupdf Build49/armv7a & Android 3.1: cycles
through subset of pages & page scrubber
The problem here was that in Honeycomb, various bitmap operations
(including drawing via JNI) do not update the bitmap generation count.
When hardware acceleration is enabled, this means that the underlying GL
layer is not aware that the bitmap has changed, and ends up reusing old
textures.
To workaround this, we erase the bitmap before drawing the page. Erase
appears to be the only operation I could find (after pouring through the
source), which actually increments the generation count. The other option
would have been to disable hardware acceleration, but that was far less ideal.
|
|
crash when rotating the device.
When cancelling a render async task, we now wait for it to actually finish
before continuing. The benefit of this is that we should be able to guarantee
that its Bitmap becomes eligible for GC before we continue to create any
new bitmaps.
This should hopefully help with the OOM errors seen when rotating
the device and trying to create the new bitmaps.
To prevent the UI thread from being blocked for too long while we're waiting
for the async task to finish, we use a fz_cookie and set the 'abort' flag to
request the render be stopped as soon as possible.
|
|
|
|
The get_globals helper function only works on non-class objects.
Hence 'MuPDFCore_javascriptSupported' can't be a static function.
|
|
Now use one-time allocation of page-sized bitmaps
|
|
|
|
|
|
|
