J
JigglyBit
Guest
Hi,
Posted similar question previously and kind of gave up with it but want to revisit. I am running into a problem (not really a problem per se, rather a slight annoyance) with necessary latency I am dealing with in reading data streams from devices that impose their own processing overhead while conveying information back to Win application. Specific issue I am running in to is I am pulling several dozen milliseconds worth of overhead from a COM port and during that time frame, operations such as dragging the GUI window are choppy. Commenting out the portion of the code that is responsible for comms puts everything back to perfectly fluid operation. This is based on timer operation, and although I appear to have all other blocking concerns worked out and the app seems perfectly fluid, I don't see a way to get around this issue where data flow is transferred outside of scope of Windows app...the app necessarily sits and waits for the handshake.
In block form this looks something like:
WndProc->switch WM_TIMER->CaptureData->RedrawBackgroundGraphicsBuffer->RedrawWindow(force NOW)
Where CaptureData looks something like:
SendExternalController() -> <wait 2 ms. for processing>-> ReadExternalController() -> <wait for processing...repeat several times> -> return
Either I am not handling this appropriately or the only other solution I can think of is to have an independent thread or .exe perhaps writing this to a data file which the GUI reads from. I had posed question about independent thread and general response was that it is not typically a good idea to pass data back and forth between threads. In reading through _beginthreadex() in conjunction with CSemaphore, it looks like there may be a way to do this but it also appears that managing multiple threads and pointers can be a real challenge. I would intend to run the parallel thread in the background the entire duration the GUI is up and it would be performing basic IO tasks and writing to simple arrays the GUI can poll.
Any thoughts on the situation?
Graphics post update.
Continue reading...
Posted similar question previously and kind of gave up with it but want to revisit. I am running into a problem (not really a problem per se, rather a slight annoyance) with necessary latency I am dealing with in reading data streams from devices that impose their own processing overhead while conveying information back to Win application. Specific issue I am running in to is I am pulling several dozen milliseconds worth of overhead from a COM port and during that time frame, operations such as dragging the GUI window are choppy. Commenting out the portion of the code that is responsible for comms puts everything back to perfectly fluid operation. This is based on timer operation, and although I appear to have all other blocking concerns worked out and the app seems perfectly fluid, I don't see a way to get around this issue where data flow is transferred outside of scope of Windows app...the app necessarily sits and waits for the handshake.
In block form this looks something like:
WndProc->switch WM_TIMER->CaptureData->RedrawBackgroundGraphicsBuffer->RedrawWindow(force NOW)
Where CaptureData looks something like:
SendExternalController() -> <wait 2 ms. for processing>-> ReadExternalController() -> <wait for processing...repeat several times> -> return
Either I am not handling this appropriately or the only other solution I can think of is to have an independent thread or .exe perhaps writing this to a data file which the GUI reads from. I had posed question about independent thread and general response was that it is not typically a good idea to pass data back and forth between threads. In reading through _beginthreadex() in conjunction with CSemaphore, it looks like there may be a way to do this but it also appears that managing multiple threads and pointers can be a real challenge. I would intend to run the parallel thread in the background the entire duration the GUI is up and it would be performing basic IO tasks and writing to simple arrays the GUI can poll.
Any thoughts on the situation?
Graphics post update.
Continue reading...