I'm working on an app that shows the floor plan of a trade fair. This is a high resolution (3500x4600), but fairly low file size (400kb) PNG image. I have a little component that allows to pan / zoom it.
Now it all works just fine on iOS, but on Android I just cannot get it to work. If I just try to load it in the normal RN (0.56) Image component I get a blank screen. I'm testing on an HTC One M8, which is not exactly brand new, but also not super low end (2 GB Ram). Funnily enough, if I convert it to a 2,6 MB jpg with the same dimensions, it will show up, though the quality is so bad, you cannot read any of the labels.
There are some mostly older github issues on this (like here and here), but none of those solutions (android:largeHeap="true") work for me.
I tried using react-native-svg, but it has the same problem (I guess it eventually gets rasterized?).
I also tried using react-native-fast-image, which uses Glide under the hood instead of Facebook's Fresco, but (you guessed it), it also doesn't work. If I just load the image, it will get downsampled (worse than the jpg). I tried to get Glide to stop doing that (using override), but then I get a blank screen again.
I found this library, which I guess does exactly what I want, but I'd have to wrap it for RN use... which would be quite a bit of work.
Anyone have an idea?
Related
So, we are using Fresco in our android app and so far it has been great. There is one issue that we are seeing when we load an image of size 8000x4500. We are seeing a Jank when that image is being loaded in the list on all devices and on some lower end devices, we are getting an OOM error (which is ok because we were testing on a 80$ device which is low on resources). Not sure if we are doing anything wrong or missing something.
In our app all images are encoded as DataUris (conforms to RFC 2397) and we are loading the images using setImageURI method.
Now my question is, does the conversion of URI to bitmap inside Fresco happens on the same thread or does it happen in a background thread? I was trying to browse the code and understand it myself, but understanding the control flow wasn't straightforward. In particular, I couldn't figure out how the mTopLevelDrawable is updated for ImageRequest of type DataUri.
Any help on understanding how it works, what could be done at the application level to prevent it would be great.
We are ok to set a maximum dimension to something like 1280 or the width of the window. Would that help reduce the decoding time?
Thanks in advance!
Note : We deliberately choose a high resolution image to understand the limits of our product. For regular sized images, things are pretty smooth. For high resolution images, even on higher end devices like pixel 4, there is a jank.
I've been playing around with Xcode and Unity for a while, and have made an app in Xcode which has a scrolling background. I want to basically re-create the app in Unity 2d, using the same set of images (if possible). I've imported all of the iPad sized images that I used in Xcode, but have noticed that the quality is a lot poorer when I build using Unity remote.
The image I'm most bothered about is the background, which is a repeating texture that scrolls across the screen. Do I have to mess around with the settings in Unity to get a better image quality? I'm using PNG. Surely the image can't be too small and therefore stretching because I'm using iPad sized images and running the app on Samsung Galaxy S6. Thanks in advance.
Unity Remote stream screenshots to your device, so the quality is not the final.
Maybe you can try to change the settings of UnityRemote.
See
http://docs.unity3d.com/es/current/Manual/UnityRemote4.html
More info/same question:
http://answers.unity3d.com/questions/408896/android-image-quality-is-poor-compared-to-the-qual.html
Find you image in Project tab and select it, then you should see something like this in inspector, experiment with values until you get results you are happy with.
I have an application with a WebView, where there's a long list of posts that Autoloads via Ajax when the user approaches the bottom of the scrollable area, so I display the word "Loading ... " and an animated GIF beside it created via Ajax Loader site.
The problem is that this Gif sometimes appear as a still image in some devices with Androind 2.3.5/2.3.6, and in other devices its animation is extremely fast, and in other devices it's extremely slow.
E.g. Galaxy S Mini with OS: 2.3.6 (it appears as a still image).
Galaxy S I9003 with OS: 2.3.6 (it plays in a very very fast rate).
Galaxy S2 with OS: 4.0.3 (It plays very fast then suddenly becomes extremely slow but it's still animating).
Is there a standard frame rate or any work-around for this issue ?,
Here's the image That I'm using:
------> <--------
I know Facebook's app was using WebView with loader at the bottom of the feed but I don't know if it was animated gif or not.
I know that older versions of Android didn't support animated GIFs but I'm talking about new version
I had exactly the same problem and found no solutions! Animated GIF behavior seems really inconsistent across devices. That's the bad news. The good news is that I've made a work around, specifically for ajax loaders like yours.
You'll need to make separate image files for each frame of your GIF. It sounds horrible but it worked out ok for me - My 8 frame 8kb GIF turned into 8 png images totaling 11kb, and I got the bonus of 8bit transparency so I don't have to worry about the background color. It does mean the client has to make extra requests for the separate images though, so the fewer frames the better. I called the images 0.png, 1.png ... 7.png and put them in a folder to keep them neat.
Now the code! I'll explain it below.
HTML:
<img src="images/loader/0.png" id="headLoader" />
<div id="loaderKicker" style="visibility:hidden;"></div>
JavaScript (jQuery):
var loaderImg = $("#headLoader");
var loaderProg = 0;
setInterval(function() {
$("#loaderKicker").html(loaderProg);
loaderImg.attr("src", "images/loader/"+loaderProg+".png");
loaderProg = (loaderProg+1)%8;
}, 300);
First we have the img that we will animate. We use setInterval to change the image url to cycle through the frames. Really short intervals obviously put load on the device so we don't want to go nuts. I have a really cheap Android 2.2 device and 200ms+ intervals seem to work ok without wrecking app performance.
The loaderKicker div is there to make this work on older devices (like the ones we're targeting :) ). Android seems to ignore the calls when all we do is update an image url, so we get around this by updating the contents of a hidden div. I tried always updating with an "x" but it seems that the content has to actually be different. The slide number works well.
So that's it! It's a bit of a hack job but it works on everything I've tested on (Android 2.2, 2.3, 4.0, iOS6, Firefox, IE, Chrome) and if you're only doing it on one ajax loader that you'll then use everywhere it seems ok.
The other, completely separate, solution is to animate the image using HTML5 canvases but I couldn't tell you anything about support for them in old devices.
I'm working on a game for android that is near completion, but within the last week suddenly the loading of Bitmap assets used in the game are throwing memory errors.
The main Bitmap in particular that it's throwing errors on is 237kb and 1792X1024 (32 bit). It is a sprite sheet for a player which is why it is so large, the strange thing is it used to load in and I can actually load in a image that's the map of the game that is 400X800 32bit file that's 413KB without any problems (that isn't a typo, the smaller resolution/same bit file appears larger. I'm not completely sure why but I'm assuming it has something to do with the colors involved or the fact the sprite sheet is predominantly transparent). All images were created in GIMP.
I'm unsure what started the errors as there was no change to anything in the code except for an update of the android API (though it would randomly give errors before in early testing). I have also tried loading in only this spritesheet by itself in a new project which it throws errors, but not on the other larger file.
To make things even more strange, I have a backed up APK from a test phone from when the game didn't throw errors that I've even tried decoding out the png spritesheet and using this exact image (and it still throws errors). The only way for it to not throw errors is to increase the VM max heap to above 24MB (the default, the smallest I've tried is 48MB and this worked but it's loading a lot slower than it used to).
Is this a possible manifest problem or did something in the SDK change that I'm not aware of? I've been trying to solve this for several days trying different methods I've found on numerous boards including setting the sample size with Bitmap.options, manifest adjustments, changing it on resize, System.gc(), recycle(), etc.
Does anyone have any idea what could be going on here?
I doubt your actual in-memory bitmap is really 237KB. I'm guessing you have a PNG that's 237KB, but the decoded bitmap is much larger in memory. PNG uses a form of lossless compression. As to why it worked before but not now I'm not sure, but I'm not in the least surprised that you're running out of memory with bitmaps that big.
You can use a tool to compact/generate your sprite sheet. Something like this might be useful:
http://spritesheetpacker.codeplex.com/
If you are getting an OutOfMemory error then I had the same problem and fixed it as follows. I truly think it is a bug in the native Bitmap code.
Here is what I did: Don't use BitmapFactory.decodeStream or BitmapFactory.decodeFile. Instead use BitmapFactory.decodeFileDescriptor
If that works for you, please let me know as it will help confirm if there is really a bug in the other methods.
I had an android app built especially for medium screen size android devices.
Now it was required to build that same app for a device called nook-color (by Barnes & Noble)
So for this we made all the images bigger & size & changed the layouts.
The result is that the apk which was 97.5 Mb earlier has now become 124 Mb in size.
Now the testers have complained that the application has become slower and it takes a little longer for any screen to open up. I am wondering whether this is due to bigger images or there is something else.
Can you please tell me what could be the reason for this.
124 Mb for an app seems to be a little bit excessive. I'd suggest trying to scale down the image assets, use Nine Patch images, as well as using PNGCrush
Yes. The delays are (at least in part) due to loading larger images (de-compressing them to bitmaps, to be more exact). Unless you can't help it, you should attempt to convert as many of these images to 9-patches : http://developer.android.com/guide/developing/tools/draw9patch.html.