Thank you very much for your advice, Matthew.
I modified the part of the code that you pointed out and tested it for the same (600,900) client size.
From (1) to (5), the speed does not depend on the client size, but (6), (7) matplot strongly does.
| Rank | test script | Speed | Modules |
|---|---|---|---|
| 1 | test_qt | 74.4 fps | pyqtgraph/PySide2 |
| 2 | test_cv2 | 63.6 fps | opencv |
| 3 | test_wx_bmp | 36.1 fps | wx using StaticBitmap |
| 4 | test_wx_dc1 | 35.8 fps | wx using DC single buffering |
| 5 | test_wx_dc2 | 36.1 fps | wx using DC double buffering |
| 6 | test_wx_agg | 11.1 fps | matplotlib with wxagg backend |
| 7 | test_mpl | 7.3 fps | matplotlib with pyplot |
test-drawing-speed-ver2.zip (5.5 KB)
On MacOS (and also “not new” hardware), I see that the absolute rates are faster, but the results mostly consistent, except that opencv is not ~80% to 90% of PyQtGraph, more like 60%, and the fastest wx times are comparable to that.
Hmmm, is that due to the version? I tested with OpenCV4.
But finally, and actually most importantly, what frame rate do you think you need?
It is difficult. 
10 fps can be stressful and I think 20 fps is enough. 30 fps is good for in-situ observation. 50 fps is a bit meaningless as it exceeds the refresh rate of the device.
I work with electron microscopy images that are 2-byte grayscale and my application handles live-view of 512 x 512 at 20 fps (= 10 MB/s) in a remote. I plan to deal with bigger images in the future. The size of 2k x 2k image was normal, 4k x 4k CMOS image is becoming standard, and 8k x 8k sometimes.
For now, the faster the better. “The practical scientist is trying to solve tomorrow’s problem with yesterday’s computer”
“Photography is Truth, and Film is Truth 24 times a second”, said Godard
Impressing! Did Godard talk about Japanese anime? 