🚀 go-pugleaf

Hi Gents,

Thanks for the info.

Essentially I've got my main program doing what windows programs do... written
in BDS2006 C++, it displays menus, buttons, etc. and waits for user interaction
with the main message loop (managed for me by Borland). I also have a seperate
thread executed by...


// spawn thread for advanced grab/display routines
hThread = (HANDLE)BeginThread(THREAD_PRIORITY_NORMAL, 0,
                              VideoGrabbingThread, this, 0, ThreadID);

// set thread priority
SetThreadPriority(hThread, THREAD_PRIORITY_LOWEST);


...which in turn executes this...


// set semaphores
terminated = false;
busy       = false;
grabbing   = true;

// grab, process, display live video as normal
while (!terminated)
{
	// give primary thread time to process frozen image
	if (frozen)
		Sleep(100);

	// grab, process, and display video data
	else
	{
		// set semaphore
		busy = true;

		// grab video frame(s) from camera
		Grab(live_grabbing_count);

		// process image data
//		Process();

		// display current image on screen
		Display();

		// clear semaphore
		busy = false;
	}
}

// allow main process to continue after terminating video loop
grabbing = false;


...Process() usually performs image processing stuff, byte by byte through the
Bitmap data. I manage all this myself without using any Windows API. Everything
is done with a unsigned char pointer in a buffer allocated by me. However, I
commented this routine out a while back and forgot to re-enable it. So, it's not
been active during my diagnosis.

So in general, 1 thread (my main app) processes event messages and 1 thread (my
own creation) grabs a video frame from the camera into a BITMAP buffer and
paints it on the screen using SetDIBits or StretchDIBits.

My problem is hard to diagnose. My symptoms are general slowness of video
refresh/update, reduced frame rate, OS crashes (blue DOS screen as "auto
restart" is disabled) with messages like IRQL_LESS_OR_EQUAL or BAD_POOL_HEADER.

A complicating factor to this is that the GUI updates in response to user
interaction. This is for a robotics app. So, when motors move, their absolute
positions are displayed immediately thru TLabel::Repaint(). I've surrounded
calls to the GUI with try/catch blocks. Is it possible this is related to my
problem? Perhaps if I configure my entire program to use a single side of the
processor then it will behave like it does on single-core machines? Can I do that?

Thank you for your assistance...

Rob