Comments (9)
Instead of modiyfing BitmapDecoderAssets, implement your own BitmapDecoder, and assign that to the TileView with TileView.setTileDecoder.
LMK if that's not clear or you need an example.
from tileview.
Yeah I realise that I can create my own BitmapDecoder however for the purposes of making it work exceptionally fast this made perfect sense (we already have a method of accessing inputstreams from the APKExtension package which is universally accessible via a singleton).
I will create my own bitmap decoder and probably call it BitmapDecoderExtensionAssets and will send it to you ;)
I'll also provide a supporting class which can provide the APK extension handling.
from tileview.
Regardless of how I'm performing the decode, it appears the ability of the TileView to load all the tiles is massively limited by the VM budget which appears to be much too small for what I'm trying to achieve. I've been looking at ways to improve the situation but I'm not able to find anything which is entirely helpful in this situation. Do you have any suggestions for how I might prevent the out of memory errors?
from tileview.
Some tips for avoiding OOM errors (specifically re: bitmap data)
- Use as low-res tiles as possible. This may seem obvious, but find out if your tiles are smaller as jpegs or pngs (you might be surprised), and (if jpg) see how low a quality you can get away with.
- Make sure you're using enough tile sets. At least a new one every 50%, but more will help (balance between total size of deliverable, and optimal memory use). This is because as a tile set scales, it's still using all the memory for the tiles, and as it becomes smaller more tiles are loaded, which could be taking up much more memory than is required.
- Use smaller tile sizes. Any tile that is showing by at least 1px will be full rendered, so if you have a bunch of 512x512 tiles and 8 of them are on the egdes, you'd save 75% of the memory by using 256x256 tiles.
- Double check that your downsamples are small enough. There's no hard-and-fast rule here, but I generally resize the original image to about 500px (as a jpeg) at a quality of 3 or 4. I usually end up with a file size of between 40 and 120KB.
FWIW, I've personally used this on 9 commercial apps, released into the wild, and dozens of apps for testing and debugging, and never get OOMs. I'm not saying it won't happen or you're doing something wrong necessarily, but for what it's worth I never see them.
HTH, LMK how it goes
from tileview.
Our tiles are 256x256 - and are as small sized as possible (indexed palette PNGs). Essentially the map is unable to load entirely in a lot of cases, throwing OOM errors. In the case of one of our maps we have hundreds of markers which are added to the map (and removed/re-added when zooming and panning) which is likely taking up more memory but that shouldn't be a huge amount.
The downsamples are pretty small, at 469x704 or 1056x704 depending on the orientation of the map. We're mostly seeing this on a galaxy S4 but the S3 is showing the same problem whereas the galaxy nexus isn't. I'm assuming that there's quite some variety between the VM size on these devices.
After spending some time with the code, I'm unable to find out where and how the bitmaps are being recycled which afaik is an important memory saving requirement according to: https://developer.android.com/training/displaying-bitmaps/manage-memory.html
If you could point me to where and how the destruction of tiles in memory is being handled there may be some improvements I can make to it.
The only alternative I have is to reduce the size of the tiles to 128x128 and hope that this will reduce the memory below the VM size just enough, however it seems more like the memory is being leaked as it works fine initially and after a few minutes it becomes almost impossible to avoid an OOM error.
from tileview.
Bitmaps are not recycled, they are nulled. If you recycle them, subsequent attempts to decode them will throw "bitmap was recycled" errors. The bitmaps are nulled in Tile.destroy
https://github.com/moagrius/TileView/blob/master/src/com/qozix/tileview/tiles/Tile.java#L88 Memory management is pretty aggressive, and it's been tested pretty thoroughly by a number of users in the previous widget with the issues you're describing. I think you're issue is elsewhere, but you're free to review and modify. I can't imagine it's leaking entire bitmaps - if it were I'd assume that any of the apps it's been in would have had similar problems.
At the start of every render pass, all tiles that don't have at least 1 pixel on-screen (including viewport padding) are scheduled to be destroyed. When the pass is complete, it re-calculates and runs again.
Assuming you're using tile sets as efficiently as possible, the only other thing I can suggest is to make sure you're cleaning up onPause and onDestroy, but if you're seeing the OOM during uninterrupted (non-onPaused) use, then that wouldn't directly apply. If you're issue is after a Pause event, then you definitely need to manage that manually in the Activity (method are provided but need to be invoked, e.g, TileView.clear
)
You might also try disabling tile transitions TileView.setTransitionsEnabled( false );
HTH, GL.
from tileview.
I've kinda gotten around this issue by adding largeHeap to the options in the manifest. I think the main reason for this occurring is that at the same time as we're loading the tiles, we're decompressing them from the obb file which is going to require the zip decompressor to be loaded too. I'd suggest making users aware of this in the future, if they're using extension packs, it's a good idea to use largeHeap :)
from tileview.
GTK. If you get a moment and want to write up some general info about using extension packs, I'll add it to the wiki.
from tileview.
can i close this issue?
from tileview.
Related Issues (20)
- Issues scaling past 1f HOT 3
- Remote tile demo freezes and crashes HOT 2
- Combine smooth scroll and scale HOT 2
- Tiles not properly laid out when Scale < 1 with remote tiles HOT 15
- Open source but no license? HOT 2
- Markers disappear when zooming HOT 4
- Cannot add tile images on the fly HOT 1
- StreamProvider asked to provide data for rows and columns out of bounds with to small images HOT 5
- Tiles outside the image are created HOT 8
- White text on white background in Advanved Tile Demo HOT 1
- Get touched position when touch on the tileview (version 4.0.7)
- longtouch
- App killed in background crashes when returning to foreground HOT 1
- `android.os.BadParcelableException` regarding `com.moagrius.widget.ScrollView$SavedState.<init>` HOT 1
- Use in viewholder for recycler view. HOT 2
- build() method starts to return void instead of TileView HOT 1
- Mike passed away HOT 5
- Does this lib support SVG format
- JCenter -> MavenCenter
- implementation 'com.qozix:tileview:2.7.7' doesn't seem to work HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from tileview.