I have a custom view where normally I was using .png files to draw onto in a canvas and that worked fine but now my requirements are to use .gif files and for some reason the same code will not work. Is there something specific about .gif files that doesnt allow android canvas objects to draw on bitmaps made from them?
Apparently you cannot draw on a canvas created from a .gif file. Once I was able to convert the .gif to .png I was able to draw on the canvas again.
Actually, I can draw GIF files on canvas, but all transparent colours turn into white! I assume it is just a bug, related to the new parameter inPremultiplied in Bitfactory.Options which probably was not tested properly.
I am really frustrated with that, since now I have to replace GIFs by PNG in all my previous applications. (Fixing the bug in the following version doesn't make any difference, since there will still be models, not supporting GIF transparency.)
Indeed GIF file has it own advantage. It doesn't support alpha or true colour, but it has transparent index which in many cases is what actually needed. If you want PNG files to be not crucially bigger in size than GIF (I assume this is the main reason for using GIF instead of PNG), convert PNG files from true color to index (colormap) format (most of graphic editor, including GIMP and Photoshop support that), which works OK with KitKat. You will still lose size, but no mare than 1%.
Related
I am getting an issue when I try to load set of images in View Pager in Android N (checking Samsung S6).
java.lang.RuntimeException: Canvas: trying to draw too large(132710400bytes) bitmap.
Image dimension is 960*720 and its size 64 k, View Pager count is 4
Now I place all the images in normal "drawable" folder. I tried by replacing all the images to "drawable-xxhdpi" but the issue still exist.
Im my case i resolved it by going to my manifest and changing hardwareAccelerated from true to false. android:hardwareAccelerated="false",
Nougat is pretty smart in optimisation. It doesn't matter in whichever drawable directory you put it in. It will detect whether the image is suitable for the fluent working of the app or not. And if it is not then it will generate this exception.
Solution:
Use Final android Resizer to generate drawables for all dpi.
Use Glide library to load bitmaps efficiently (it supports bitmap caching and bitmap pooling).
If your image is of single coloured (like icons) then you can generate vector drawables from .SVG or .PSD files. Learn more here.
Good luck :D
Is it possible in Android to use the Vector images (for example, contours made in Adobe Illustrator) to be drawn on Canvas?
I looked at Vector graphics in Android but I don't want to use any additional third-party libraries.
So, is there any another way to make this idea?
One thought, that came to mind, was to convert to the 9patch images. But still I'm not sure whether it sounds good.
All of fuss just over the aim to make the complex countour from which I want to create android.graphics.Path using public void addPath (Path src, Matrix matrix) function.
You cannot use vector images in Android, at least with the built in SDK.
It may exist libraries to use vector images, but this is not the Android best practice.
What you need to do in order of not pixelating/blurring your images is to use the different drawable folders existing in android.
You should provide different images depending on the screen density of the display, and android will pick the correct one in runtime.
http://developer.android.com/guide/practices/screens_support.html
9 patches are good only if the image is meant to stretch to fit its content, while its borders should repeat following a pattern. The typical use of this are buttons. For images that dont work as the background of a View, 9 patches are not a good option.
Images in apps come in many shapes or sizes, but to save space and editing time is there a way to use scaleable vector images?
Ideally I would have one vector image at middle resolution, I could then detect the screen size and scale the vector how I need and add the background using some custom gradients.
I'm using titanium for this.
Titanium doesn't yet support vector graphics, though it is available in native Android code via Shape Drawables. There is a third-party SVG library available for Android SDK.
For Titanium, branch the code based on the device screen size (Titanium.Platform.DisplayCaps), and find an image that works with decent performance on the device.
You can use PNGs with transparency and apply a background color to your view object.
I've found away round making different sized drawable:
Basically just one have folder called drawable within the res folder.
Make your artwork in what ever you use but make it large (at least 1080p for future devices).
Save the image's as PNG within the drawable folder but save them large. (IE at least 1000x1000)
Write a function that loads in the PNG but scales it (according to screen size & percentage of what size you want the drawable to be. So 20% of 800px width is 120px). I've managed to do this bit with 30ish lines of code, can't paste my code since I'm not on my working machine.
For me this has worked across all my apps for all devices, I've not had a single crash yet (1000's of installs, including Live Wallpapers).
I've run into issues with banding of my PNG files. Digging into the problem has yielded two solutions. Both make sense individually, but together they don't. The solutions I've discovered:
1) Move the PNG file into the "raw" folder. This prevents AAPT from "optimizing" the image which results in banding.
2) Change the pixel format of your Activity's window to RGBA_8888 (i.e. in onCreate add this line "getWindow().setFormat(PixelFormat.RGBA_8888)"). On Android 2.2 and lower the default pixel format is 16-bit (565).
I have tried both of these and they correct the banding effect in my images, however now I am even more confused as to what Android is doing.
On the one hand, if I leave my PNG in the drawable folder it is "optimized" which results in a banding effect in the image. It magically goes away when I change the pixel format to 32-bit. If the image was "optimized" though, I would have expected the banding to remain.
On the other hand, if I move the PNG to the raw folder it will retain the nice gradient and display nicely even though the pixelFormat is supposedly 16-bit.
If anyone has any insight into what is going on I would appreciate it.
Thanks,
-Dan
I believe its quite simple :
You have to think of the pixel format of your Activity(RGBA_8888) as a DEFAULT optimization for your bitmaps.
If it is not set, then prior to 2.2, by default it will compress your bitmap to RGB_565.
But if you were to create programmatically a bitmap and set it to RGBA_8888, then it would be used as such by the app.
Same applies when you put your bitmap in the raw folder : Even though the default PixelFormat is set to RGB_565, the activity will use it as it is without "optimizing" it.
When you put your bitmap in the raw folder it will not be compressed at all and used as is even though the default PixelFormat is still RGB_565.
I'm having trouble making my texture rendered correctly in my applications.
the artwork I use is precise and already scaled and the right size but when I render it on phone suddenly my texture are not as clear/precise as the original artwork and I can't figure out why.
has anybody had this issue before?
This is because android will compress all resources that are not placed inside /res/raw/
http://developer.android.com/guide/topics/graphics/2d-graphics.html
Note: Image resources placed in res/drawable/ may be automatically optimized with lossless image compression by the aapt tool. For example, a true-color PNG that does not require more than 256 colors may be converted to an 8-bit PNG with a color palette. This will result in an image of equal quality but which requires less memory. So be aware that the image binaries placed in this directory can change during the build. If you plan on reading an image as a bit stream in order to convert it to a bitmap, put your images in the res/raw/ folder instead, where they will not be optimized.
This might also happen if you use linear filtering in your texture, make sure that texture filters are GL_NEAREST for GL_MIN_FILTER and GL_MAG_FILTER.
Ok I finally figured it out
the problem I was having was coming from the default compatibility mode of android
I had to add this to my manifest