OpenMV IDE locks up when sending lots of data very fast

[JamesNewton]

After upgrading the IDE to 2.6.5, I find it locks up when I try to select any text in the terminal. If I don't try to select anything, it seems to work ok. But a mouse drag over the text seemed to fry it.

After a little debugging, I realized that before I started to select text, I was always sending a command to stop more data, and my program was actually sending data as fast as it could. So that's probably the actual cause of the issue. 

If I use e.g. PuTTY in serial mode, I can connect and do the same thing, and it does NOT lock up PuTTY. 

I'm not sure that is something you can stop, but people should know it's a possible problem and that a work around is just to add a pause in any loop to keep from overwhelming the terminal. 

I'm (still) running Windows 7 on this machine and have not tested it on my Ubuntu 16 or 18 machines. More modern or different OS's may not have the issue.

P.S. A few notes on working with the camera directly from the terminal without using the IDE:
HaddingtonDynamics/Dexter#107

[kwagyeman]

Yeah, there's just one thread in the IDE rendering everything. I don't really have any plans to fix this. To avoid the lockup I'd need to change the serial terminal buffering to be quite different.

How much text are you sending to the terminal? It's not necessarily designed to be sent ridiculous amounts of text.

To note, it's a row buffer architecture. So, it's quite good receiving long lines. But, every line it receives makes it work harder. So, if you make the lines longer that's better for it.

[JamesNewton]

I've noticed exactly what you describe. xfering back an image in base64 (massive single line) does't cause a problem, but sending a ton of little short lines kills it.

I would suggest a documentation solution. E.g. "To avoid overwhelming the terminal, always include a delay in any loop" Or just close this and hopefully people will find it.

[kwagyeman]

Probably this issue is sufficient. Google picks up these easily.