Curious if this is so broadly true without bundled resources; obviously screens are higher DPI, so even buttons are now designed for at least 8K resolutions, even if most consumers are still on 1080p.
Orders of magnitude beyond 640x480 or pre Windows 3.1 resolutions.
Many apps ship both vectors and raster images. It is worth nothing that vectors save space, but increase compute (the image now has to be rendered at runtime), contributing to slower startup times.
In practice, that cost of rendering the vectors vs images is negligible because rendering a raster image isn’t free either. Especially, if you’re going to package large images in your app.
Raster images do not need to be rendered - see Rendering:
Rendering is the process of generating a photorealistic or non-photorealistic image from input data such as 3D models…Today, to “render” commonly means to generate an image or video from a precise description (often created by an artist) using a computer program.
Note that “render” is a fairly generic term, and it is sometimes used like “render to the screen,” to just mean to display something. Rasterisation may be a better term to use here, since it only applies to vector graphics, and is the part of the process I am referring to.
In any case, except for possibly reading fewer bytes from disk, the vector case includes all the same compute and memory cost as the raster image - it just has added overhead to compute the bitmap. On modern hardware, this doesn’t take terribly long, but it does mean we’re using more compute just to launch/load things.
I meant render in a sense of displaying the encoded data as pixels on the screen. I understand how different kinds of rendering work. My point is that reading and displaying image data isn’t free. It can be cheaper than drawing vectors, but there is still a cost and it grows with the size of the image. Images also end up eating up more memory as a rule.
Curious if this is so broadly true without bundled resources; obviously screens are higher DPI, so even buttons are now designed for at least 8K resolutions, even if most consumers are still on 1080p.
Orders of magnitude beyond 640x480 or pre Windows 3.1 resolutions.
A lot of that done using vector graphics though.
Many apps ship both vectors and raster images. It is worth nothing that vectors save space, but increase compute (the image now has to be rendered at runtime), contributing to slower startup times.
In practice, that cost of rendering the vectors vs images is negligible because rendering a raster image isn’t free either. Especially, if you’re going to package large images in your app.
Raster images do not need to be rendered - see Rendering:
Note that “render” is a fairly generic term, and it is sometimes used like “render to the screen,” to just mean to display something. Rasterisation may be a better term to use here, since it only applies to vector graphics, and is the part of the process I am referring to.
In any case, except for possibly reading fewer bytes from disk, the vector case includes all the same compute and memory cost as the raster image - it just has added overhead to compute the bitmap. On modern hardware, this doesn’t take terribly long, but it does mean we’re using more compute just to launch/load things.
I meant render in a sense of displaying the encoded data as pixels on the screen. I understand how different kinds of rendering work. My point is that reading and displaying image data isn’t free. It can be cheaper than drawing vectors, but there is still a cost and it grows with the size of the image. Images also end up eating up more memory as a rule.