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.

It’s also worth noting apps have to ship higher resolution assets now, due to higher resolution displays. This can include video, audio, images, etc. Videos and images may be included at multiple resolutions, to account for different sized displays.

For images, many might assume vectors are the answer, but vectors have to be rendered at runtime, which increases startup time in the best case scenario, and isn’t even always supported on all platforms, meaning they have to be shipped alongside raster assets of a few different sizes, further increasing package bloat. And of course the code grows to add the logic to properly handle all the different asset types and sizes.

All this (packaging dependencies, plus assets/asset handling) to say it isn’t always malware, ads, electron, etc. Sometimes it’s just trying to make something that looks nice and runs well (enough) on any machine.

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.

Thanks! I am in the US. I’ve never heard of RH, but I’ll definitely check them out.

Can you describe your use case more?

I don’t think format matters - if you’ve got multiple processes writing simultaneously, you’ll have a potential for corruption. What you want is a lock file. Basically, you just create a separate file called something like my process.lock. When a process wants to write to the other file, you check if the lock file exists - if yes, wait until it doesn’t; if no, create it. In the lock file, store just the process id of the file that has the lock, so you can also add logic to check if the process exists (if it doesn’t, it probably died - you may have to check the file you’re writing to for corruption/recover). When done writing, delete the file to release the lock.

See https://en.wikipedia.org/wiki/File_locking, and specifically the section on lock files.

This is a common enough pattern there are probably libraries to handle a lot of the logic for you, though it’s also simple enough to handle yourself.