What operation costs more - Image loading or image resizing?
-
The answer probably depends on what definition of cost is used.
For most cases, I imagine that loading a new image is more expensive. If the image provider reads a file from a filesystem, there's probably at least two context changes, storage I/O, memory allocation, and image format decoding.
Resizing might not need anything other than allocating memory and the equivalent of decoding. It might still result in context changes and hitting storage if memory swapping is involved.
-
As jeremy_k already pointed out, loading an image from disk is pretty expensive. Resizing an Image element live using width/height can be considered a noop.
This isn't entirely true of course, because:
- The bigger the area the image fills, the longer it will take to draw it
- The bigger the source image, the longer it will take to draw it
- If the image has alpha channel, it will take longer to draw it
but the act of resizing itself adds nothing.
Now, you talk about scaling down by from 100x100 to 50x50. This offers a different problem, which is that Images with smooth: true, will use linear interpolation and will start to show artifacts when the scale factor is less than 0.5. This might be ok, and it might not. Depends on the usecase.
If it is not ok here is what you can do. If the small image is static and loaded only rarely, use the sourceSize, which for a 50x50 image, though slow, will be acceptable. If you combine it with Image.asynchronous: true, it won't impact the UI / Render threads, so the application won't suffer.
The other alternative if the image needs to be resized live and to sizes only known at runtime, use Image.mipmap.
