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.

I’ve had the same problem with HeliBoard learning garbage. I just changed my settings though, and I think it should help:

1. Open HeliBoard settings
2. Open Text correction settings
3. Scroll all the way to the bottom, and turn off “Add words to personal dictionary”

If you scroll all the way to the top again, you can manually manage the personal dictionary, including adding words you do want, and deleting any junk that was added by mistake, before switching that setting off.

If your drive is the bottleneck, this will make things worse. If you want to proceed:

You’re already using ffmpeg to get the sequence of frames, correct? You can add the -ss and -t flags to give a start time and a duration. Generate a list of offsets by dividing the length of video by the number of processes you want, and feed them through gnu parallel to your ffmpeg command.

My first thought was similar - there might be some hardware acceleration happening for the jpgs that isn’t for the other formats, resulting in a CPU bottleneck. A modern harddrive over USB3.0 should be capable of hundreds of megabits to several gigabits per second. It seems unlikely that’s your bottleneck (though you can feel free to share stats and correct the assumption if this is incorrect - if your pngs are in the 40 megabyte range, your 3.5 per second would be pretty taxing).

If you are seeing only 1 CPU core at 100%, perhaps you could split the video clip, and process multiple clips in parallel?

it doesn’t unravel the underlying complexity of what it does… these alternative syntaxes tend to make some easy cases easy, but they have no idea what to do with more complicated cases

This can be said of any higher-level language, or API. There is always a cost to abstraction. Binary -> Assembly -> C -> Python. As you go up that chain, many things get easier, but some things become impossible. You always have the option to drop down, though, and these regex tools are no different. Software development, sysops, devops, etc are full of compromises like this.

I currently have a System76 laptop, and sincerely regret my purchase. When I purchased it, the Framework was not out yet - I wanted to support a company that supports right-to-repair, and figured since they controlled the hardware, firmware, and software (Pop!_OS), it would be a good, stable experience. It has not been, and support has generally been poor. I know other people have had better experiences than I have, but personally, I won’t be buying from them again.

I haven’t personally used Purism, but former co-workers spoke really poorly of them. They were trying to buy a big batch for work, and said the build quality was awful. Additionally: https://youtu.be/wKegmu0V75s