Add notes on performance for Qt bitmap present

[almarklein]

Intro

In benchmarks that I did for #138, I observed that the Qt backend is quite a bit slower than the experimental Cocoa/Metal backend. So I looked into whether its performance can be improved. I suspected that the painter.drawImage used software rendering.

Result

I tried a few things, but did not find a way to make it more performant. Using QOpenGLWidget does lead to reduced CPU usage, possibly at the cost of GPU usage.

My take on this:

• I think that the painter.drawImage() in QWidget indeed uses software rendering.
• I think that the painter.drawImage() in QOpenGLWidget does some rendering on the GPU.
• I also suspect that it renders to an offscreen OpenGL texture, and downloads the resulting image to composite it with the rest of the UI, which would explain why it's not actually faster.

All in all, I propose we leave the implementation as-is.

More notes

• Even if I make _rc_present_bitmap() a no-op, it's slower than the experimental Cocoa backend with the same method a no-op. This suggests that some of the overhead is due the Qt event loop.
• The experimental Cocoa backend is lightning fast because it uses a Metal texture that lives in RAM, so the costs is basically making one data copy. We should not expect to be able to achieve that speed in a GUI framework.
• A future backend for QtQuick would very likely be more performant, because it does compositing on the GPU.
• Some of the results may be different on other systems (dedicated GPU etc).
• In the end, 75 FPS on 4k is still pretty neat.