Can the canvas upload be faster on slow computers?

[Dawoodoz]

On a fast computer, upscaling and uploading the canvas only takes a millisecond. On a slow computer limited by memory bandwidth however, upscaling and uploading the canvas takes 25 milliseconds (90% of the total frame time).

No GPU
Many of the worst case computers do not have any dedicated graphics card, and might not even have integrated graphics or GPU drivers. So using different graphics APIs to upload the canvas would end up making it even slower by emulating random access texture sampling on software emulated graphics drivers.

No native resolution change
Changing screen resolution from the application is one of the most common cause of crashes in mainstream media layers, because there is no resolution that is guaranteed to be supported. Most users do not have a CRT monitor capable of changing the native resolution, so you would ether fake it with GPU drivers, use a scaler in the computer screen, or crash because neither was available. Changing desktop resolution manually before starting a game does give better performance without causing crashes, but it gives blurry pixels with bi-linear interpolation, has less margin to scale the image properly, and mess up the desktop shortcuts.

Optimize upscaling?
Using zip and shuffle operations for vectorization on multiple threads might improve the performance of scaling up pixels, but the worst case computers only have a single ARMv6 CPU core without any useful SIMD instructions.

Shared memory?
Because a swap-chain is already used, there might be alternative ways to show the pixels without making a memory copy. This would probably rely on non-standard extensions and ugly memory hacks.

[Dawoodoz]

The X11 shared memory extension XShm might give improved performance when available according to XShmQueryExtension.

[Dawoodoz]

On MacOS where background threads may not access the window, it might be possible to upload the original low-resolution canvas, select nearest interpolation mode, and resize the frame to canvas size times pixel scale. Then the compositor can use any available hardware for upscaling as fast as possible, without having to depend on a specific version of Metal.

[Dawoodoz]

If one can skip attaching the same pixel buffer again on recurring canvas uploads to Cocoa, one can probably just copy data to the buffer connected to the view on a background thread. This however assumes that MacOS does not make another copy of the canvas, so it might not work on every computer.

[Dawoodoz]

Tried to change the content of a previously uploaded image, but MacOS had only looked once at the data, so the image just froze. Then there is not much one can do about Cocoa being a horribly slow single-threaded API, and applications might have to be designed around it by doing the actual rendering in background threads while the main thread uploads results.