i have indeed compiled for debugging - will try and compile it for release and see. although the gut feeling says the bottleneck is on the camera side.
You can try disabling the image processing (and drawing) code. That is, make it just receive the image data from the camera but no do anything with it. This won't necessarily give you the maximum output of the camera, but it might be a lot closer.
i will do that once the VB Port is complete, i am in a little fix ive got everything on VB but the code fails at
get_video_details() while doing a connect
Sendrequest() - returns ok
ReceiveData() - returns ok
ReceiveResponse() - fails with a timeout at _device.reader.read()
though the problem may be at sendrequest() as i may have messed something and may be sending the command wrong. ill modify your original code to include sent and received response to the log and see what i am doing wrong.
Perhaps it could also be you are not using a USB 2.0 port?
i always verify that the USB and the Cable is V 2.0 compliant. this was very much the issue while using the camera (older versions SX 110, SX 100, S5, S3 etc) with the CANON SDK which was very picky about V2.0.
however i feel that the connection with CHDK-PTP is much more stable and forgiving.
just a thought - can a loop be incorporated in to the CHDK itself which will post the image at regular intervals which the receiving program collects - maybe on another thread ? so instead of requesting one instance of the image the command from the computer turns on the feed which the camera posts and another command which can turn it off - maybe suspending the loop while other commands are received if necessary