I want to create a bitmap from a view in Android, which basically works fine using the following approach: http://www.aquajava.hu/2011/06/19/converting-view-to-bitmap-without-displaying-it/
However, I want to modify this approach. Basically, my application supports multiple display densities for all kinds of resolution. Instead of creating a bitmap from a view based on the device's display, I want that the bitmap created always relies on the HDPI version. So although the display is maybe smaller I want to create a bitmap with 480 * 800 pixels. If I just increase the size of the bitmap, the font sizes and images still stay small according to the density. I don't want to just scale the image because the resolution would be quite poor then.
So basically, I search for a way to create a bitmap from a view ignoring the density of the view.
Does anybody know how I can solve this?
Have you tried calling setDensity on your Bitmap?
Related
I'm currently facing several performance issues (out-of-memory) when handling a vast amount of bitmaps. As this is just a problem that can be fixed I'm wondering if anybody can explain me the difference in using the following methods.
If I only want to load an image into an ImageView I usually use:
imageView.setImageDrawable(getResources.getDrawable(R.drawable.id));
If I want to sample the drawable beforehand I usually use (here without sampling):
Bitmap bm = BitmapFactory.decodeResource(getResources(), R.drawable.id);
imageView.setImageBitmap(bm);
My question is related to performance optimisation. I'm wondering whether it is better to provide as many drawables as possible using the different drawable folders (so these drawables nearly fit the required resolution for the different devices) or if it is better to sample high-quality drawables? What is setImageDrawable doing internally? Does it decode the resources using the BitmapFactory, just without sampling? There seems to be a trade-off between the actual size of the app and the cpu- and memory-load during runtime.
if you're concerned about apk size, then having as many drawables as possible is not the ideal way to go. but dont forget, when you decode a bitmap, you can pass a sample size so it will scale down to the screen size and only give you the pixels you need, so older phones with smaller screens wont need to decode 8mp images.
check BitmapFactory.Options and here
Reference the image attached. How to set such an image as background?
Does using 9-patch makes it possible?
Yes, Please Use 9-Patch image and Please check this on how to draw 9-patch image and also this Video Tutorial
Refer to your ldpi, mdpi, hdpi, xhdpi, and xxhdpi folders there you will have to format your image to fit the particular sizes of each screen. Another way of doing it would be android:setbackground="#drawable:example"; in your xml and testing your app out in the emulator on all the different screen sizes to see if it really matters that much due to the simplicity of your image.
It would be much simpler to create a high res .png file in your case. and might end up working better (just a thought)
If attached image is the only case, then you could try and create your own drawable by extending Drawable class.
It's just a rectangle with circles cutout on each side. This can be easily drawn using drawRect and drawCircle. This way you'll get perfect quality on every screen.
I'm having trouble cleanly down-scaling images on Android. I'm looking to scale small PNG images between arbitrary sizes of about 10-100% of their original size.
I've created a sample image to demonstrate the problem and exacerbate the unusual behaviors I'm seeing in Android's image scaler:
The above image is a screenshot from an Android device with some annotations added. I've also added the same images in a second column on the left side showing how they are rendered with a linear scaling by "The GIMP" (GNU Image Manipulation Program).
The base image consists of a checkerboard pattern background of red and blue pixels. On that background I've drawn some 1px-wide yellow lines and fairly thin green text. The image is 288x288 pixels.
When scaling the image to 1/3 of its original dimensions, Android seems to simply grab one in nine pixels, throwing out all other data. Some of the yellow lines disappear entirely as a result. Remarkably, the checkerboard pattern remains intact (which is simply a result of every 3rd pixel being used).
When scaling the image to a dimension of near-but-not-exactly 50% of its original size, e.g., 142x142 or 143x143, the scaler creates some fairly large anomalies/artifacts on the image.
At 50% size (144x144), the image looks correct.
The test image does bring out the worst of the image scaler, but "normal" PNG icon images are severely impacted as well. From 10-33% or so the images aren't properly resampled, and thus appear extremely "bitmapped". And certain larger size images have very strange anomalies in them at certain sizes.
If anyone knows a means to disable this strange scaling behavior, even at a performance cost, I'd greatly appreciate knowing about it. It can certainly be solved by writing an algorithm that works directly on the pixels of bitmaps, but I'm hopeful that isn't the only option.
Also noteworthy is the fact that all image work is being done with ARGB_8888 Bitmap.Configs. I've tried manipulating image size by setting maxwidth/maxheight on ImageViews, by using Bitmap.createScaledBitmap(), and by using Bitmap.createBitmap with a Matrix. All attempts have this same result. Bitmap filtering is enabled.
Thanks again for any suggestions!
Using Bitmap.createScaledBitmap() and Bitmap.createBitmap with a Matrix is the same; see the source for Bitmap.createScaledBitmap (which hasn't changed since Android 2).
On Android 4.0+, using a matrix (as in Bitmap.createScaledBitmap) allows hardware-accelerated operations if enabled (enabled by default on 4.1+ IIRC), thus we doesn't have direct control over what is being done and how it is done.
That means you'll have to implement your own scaling method using the desired (here, linear) filtering; either by pixel processing; or using OpenGL ES with the good filter, but it may not be available on all devices.
I have 270 x 2693 pixel image in drawable folder . When i try to set that image in imagview i got Bitmap too large to be uploaded into a texture warning.
Image sets perfectly in android device < 4.0 but not sets > 4.0 device.
Please help me to resolve this issue.
Code
<ImageView
android:id="#+id/imageView"
android:layout_width="fill_parent"
android:layout_height="wrap_content"
android:scaleType="fitXY"
android:contentDescription="#string/name"
android:src="#drawable/hindi" />
Here hindi is a image in drawable folder and its size is 270 x 2693 pixel.
Problem
This problem is usually related either to OpenGL maximum texture size or the Device Memory. The full error you are getting is probably something like
W/OpenGLRenderer(12681): Bitmap too large to be uploaded into a texture (270x2693, max=2048x2048)
Memory is generally the problem with a large scale image but in your case 270x2693 is 727110 pixels. If you are in RGBA, it's 4 bytes per pixel so 727110 * 4 = 2908440 bytes, which is approximately 2,7 megabytes. That should fit on any devices.
Thus, your problem is probably related to OpenGL. What might happen is that the Android device > 4.0 you are testing on detect that your image is too large for OpenGL and resize it for you, while older devices don't.
Edit:
In my case, the problem is that my 640x1136 splash image seems to get rezised automatically to a 1280x2272 image size to fit my device huge screen. Which also triggers the error message you are having.
If you get this error further on, it is related to the dpi that is used to load the image. As you will find on Android reference, device will load image regarding their dpi which can alter the size of image that is loaded in memory.
Solution
You don't have much choice other than detecting the device size to
load the image properly.
See how to load large bitmap in memory.
You can also use different image size for different device dpi which
can be automatically selected from the Drawable folder by Android.
See the How to support screens which tells you how to setup your
folder.
As other stated, use a smaller image or reduce its size.
Related informations
I suggest you have a look there if you need to support multiples screens.
Android also collect data which are updated every 7 days on Screens size among their users.
Also have a look to this interesting answer which points out a good website to understand Image Size in memory.
Finally, if you are already using OpenGL in your app, have a look to this answer which shows how to detect the max OpenGL texture size.
Why not reduce the size of the image? If you don't want to do that, then rather than specify the bitmap in the XML, load it from program code, and scale it to fit the display. See this guide for more information on loading large bitmaps.
try use this code
int[] maxTextureSize = new int[1];
GLES10.glGetIntegerv(GL10.GL_MAX_TEXTURE_SIZE, maxTextureSize, 0);
maxTextureSize stores the size limit for decoded image such as 4096x4096, 8192x8192 . Remember to run this piece of code in the MainThread or you will get Zero.
As part of this application I am making, I want to change my wallpaper on my android device based on a bitmap that the user has selected.
I am able to change the background. However, the background is a completely distorted version of the bitmap. Any idea as to why this would happen?Here is my code:
Bitmap bitmap = ((BitmapDrawable)currentDrawable).getBitmap();
this.setWallpaper(bitmap);
My bitmap has a width of 240px and height of 180px. My emulator is of a size 480px by 800px.
I can scale my bitmap to 480px. However, the bitmap still ends up being distorted on the android wallpaper. Any thoughts on how this can be fixed?
Thanks in advance
You should create multiple images, for each potential (and common) resolution. You don't want any scaling, or the image will be distorted.
UPDATE:
Here is a ton of good information on support multiple screen sizes:
http://developer.android.com/guide/practices/screens_support.html
The wallpaper used by the default Launcher is bigger than the actual screen, that's why you can scroll the content and the wallpaper too.