I would like to know what the pros and cons of using drawable vector shapes (XML files) vs image resources (png files) for icons (Material Design Icons)?
As I see, the question refers to general alternative between raster (e.g. jpeg, png) and vector (e.g. eps image). In one sentence, vector can be easily scaled and required less memory, but is more complicated. In details, see e.g. here.
The difference stands in vector images describing what they want to draw and raster images describing the color of each pixel, due to which these are heavier in size.
Vector images can be resized flawlessly, while attempting it on raster images is always a bad idea, which makes those images lose their quality.
Moreover, vector images are rendered slower than raster ones when there are many elements, due to the computations necessary to parse paths and shapes and draw them (indeed, vector images are more CPU intensive to render). Rather, it is faster if there are just few elements and paths have few points. Though vector images are lighter to load (in RAM; in fact they cannot be loaded in the GPU memory, unlike raster images), which makes them the fastest.
The important is, don't exceed with the number of elements in SVGs and other vector images. Otherwise, they'd end up being slower.
It depends on your needs to use which one. you can change vectors attributes with xml code anywhere you want. but image resources has less Flexibility to control its attrs and use more memory
Related
VectorDrawable is a new feature for Android after API Level 21, Which add support for vectorgraph. But I have a question for VectorDrawable, is it suitable for me to replace most of images in my project to VectorDrawable. In the android offical dev site I saw a few words :
A vector drawable is appropriate for simple icons. The material icons provide good examples of the types of images that work well as vector drawables in an app. In contrast, many app launch icons do have many details, so they work better as raster images.
Is that means VectorDrawable is only appropriate for simple icons like offical material icons, images have many details aren't appropriate to use VectorDrawable.
Sorry for my poor english skills, hope you guys can understand me! 😬
I plan to use VectorDrawable for all my project image resource if it is ok.
You're basically right.
Vector images describe shapes and geometry, and need to be rendered into bitmaps (a grid of pixels). This requires some math, calculating the pixels that represent the lines and curves defined by the icon.
The more complicated an icon gets, means the more shapes that are required, and the more calculations that need to be done.
On the other side, if you already have the icon rendered to a specific scale, like with png images, all of the pixel values have already been calculated. Now it just needs to be converted to a bitmap and scaled to the size it gets displayed at.
So depending on the situation, an icon may be able to decode and scale from a png file faster than rendering from a vector drawable, or vice versa, it all depends on the icon.
It's hard to say exactly how simple an icon needs to be, so try it out and make sure it runs well on a range of devices.
In terms of RAM utilized by a drawable when it is rendered on on the screen, does it make any difference if the drawable is a vector or a bitmap?
I understand that vectors take less media storage space, but I'm asking about the resident RAM needed in order to render it, since in theory, it is still being drawn onto a canvas with the same amount of pixels in the end.
Thanks!
From the document I read sometime ago (same question with you).
The different between these 2 options is the size of APK file after all when you release. SVG will help you save size of apk.
The initial loading of a vector graphic can cost more CPU cycles than the corresponding raster image. Afterward, memory use and performance are similar between the two. We recommend that you limit a vector image to a maximum of 200 x 200 dp; otherwise, it can take too long to draw.
Being drawn on view will have those 2 options having same RAM (memory) consumed.
My reference source: https://developer.android.com/studio/write/vector-asset-studio.html#about
use vector drawables for simple shapes. Using the same for complex structures will increase the size of the apk rapidly.
Android Lollipop has introduced several new classes, one of them being VectorDrawable. I was just wondering when will it be suitable to use VectorDrawable over a bitmap image knowing VectorDrawable has a performance drawback. The only thing with VectorDrawable is scalability which comes at the cost of performance. So when is it that I can use a VectorDrawable if performance is the priority? Is the performance drop too high?
I think the "performance drop", if present, would be acceptable. One would hope you are not creating a ton of vector drawables every frame. Presumably, you would load the VD once, cast it into a drawable at which point the vector drawable isn't needed anymore.
Really the only thing that I can see that would cause an issue, is if you are loading an absurd amount of them all at once. But why would you? At that point, just something like a presized sprite sheet.
Note that VectorDrawable (comparing with BitmapDrawable), only has the initial drawing performance overhead. After the 1st frame the VectorDrawable show up, the framework will have a bitmap cache. From that on, all the performance of that VectorDrawable should be the same as the BitmapDrawable, as long as the size didn't change.
VectorDrawable is not recommended for huge background image, like full screen size, but for buttons and icons whose size is normally smaller than something like 200dp x 200dp. You should be able to use it without worrying too much about the performance.
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.
To what extend do color depth and compression level of the original jpg and/or png images used as drawables have an effect on the app's UI performance, given the fact that all images are converted to bitmaps internally anyway.
Especially considering i.e. images in list views for example.
Same question goes for png vs. xml shapes as drawables.
Edit: I found a similar question which addresses memory usage, but my focus is more on UI performance (i.e. scrolling long list views, etc.).
Is decreasing size of .png files have some effect to resulted Bitmap in memory
Larger images probably take longer for decompressing, but when they're cached properly (and i.e. asynchronous lazy loading), after initial loading, it shouldn't matter anymore.
If the images are indeed all are converted to bitmaps internally anyway, then I think you're right, the compression level of the original file makes no difference once the image is loaded.
Color depth of the image, on the other hand, would still be a preserved difference, right? I.e. image files of different color depth on disk can be loaded to in-memory images of different color depth. So I would expect "deeper" images to have an adverse effect on performance eventually.
But as always, you never know for sure about performance till you run tests.