active window blanking out / and sticking in the corner

[sjn3]

I'm running 2 DMKBUC03 USB cmos cameras, with Imaging Control 3.1 compilling under VS2008 ( C++, no mfc, no CLR, winXP, x32). I'm using the cameras in grab mode. I inherit from the DShowLib::GrabberListener, and copy some data into a buffer in the FrameReady, and draw the frame count on the overlay call. I included some code showing how I setup the camera below.

I'm having 2 issues:
1. When I run the program in release mode and start the window the active window display will white out completely after a variable amount of time. The frames are still coming in as evidenced by continued calls to FrameReady. The problem seems to be exacerbated by moving other windows on the screen. Is the update window thread starving? Can I set it’s priority? Do I need to occasionally send my own WM_PAINT message to this window?
2. When I start in debug mode, I get the frame image and the overlay , and both update appropriately, but I get no windows bar.

CAMERA setup -----


m_grabber.getOverlay()->setEnable( true );

// Register the pListener object for the frame ready and
// the overlay callback event.
m_grabber.addListener(
&m_ImgSrcListener,
GrabberListener::eDEVICELOST
| GrabberListener::eFRAMEREADY
| GrabberListener::eOVERLAYCALLBACK );

// Create a FrameTypeInfoArray data structure describing the allowed color formats.
FrameTypeInfoArray acceptedTypes = FrameTypeInfoArray::createOptimalTypesArray();

// Create the frame handler sink
m_pSink = FrameHandlerSink::create( acceptedTypes, 100/*NUM_BUFFERS*/);
// enable snap mode (formerly tFrameGrabberMode::eSNAP).
m_pSink->setSnapMode( false );
// Apply the sink to the grabber.
m_grabber.setSinkType( m_pSink );

---------Grabbing images (in another function


m_bRunning = true;
SThread::Sleep(1000);
m_grabber.startLive(true); // Start the grabber.
m_sm_WaitForAcquireDisable.Lock(-1);
m_grabber.stopLive(); // Start the grabber.

[Stefan Geissler]

Hello,

we checked the ActiveMovie Window with similar code than yours. In our tests, the live video was shown all time, the window did not blank out.

The ActiveMovie Window has no message queue. Therefore, it has no WM_PAINT and other messages. It is even not possible to move this window.

In our tests the ActiveMovie window had a borderwith title bar in debug and release version in Windows 7. In Windows XP there was no border and title bar. I suppose this is an effect of the OS or the installed DirectShow version.

Using a DMK causes on my old computer the graphics board to use real hardware for displaying. Therefore, maybe the graphics board driver can cause the out blanking after some time. But this is only guessing. I am very sorry for this.

[sjn3]

What version of directShow do you recommend? I updated this morning to window sdk v7.0, rebuilt and still have the same issue. Does directShow depend in anyway on the version of DirectX - it would seem not from what's written in msdn about DirectShow – it’s all in the Windows SDK now, correct?

Is there any way for me to force a window bar not to form around the display – like what I get in debug mode? Oddly if I attach the debugger to the release build I get the no frame problem - which is infinitely better for me than the whiteout problem – but I can’t keep attaching the debugger in our final sw. And I can still move the windows programmatically with grabber.setWindowPos.

It sounds like you can reproduce the no frame problem but not the whiteout problem. I can even see the whiteout problem with the callback sample (with mods to make it acquire in a loop, and I took out the image saving) in the Imaging Control 3.1 samples. I tried using snap mode in a loop, and I still see the issue.

Also I don’t remember seeing this issue (window whiteout) with VS2005, and I’ve been using the camera’s for about a year with VS2005. I will try to reproduce with VS2005.

Are there other display options I should explore that will get me around this problem. Does the C# display use directShow underneath?

I’m thinking of rolling my own display, but would rather not if I can somehow salvage this one.

[sjn3]

The whiteouot problem does not occur with VS2005. Only with VS2008.

I really don't want to revert to using VS2005. Any ideas? Thanks.

[Stefan Geissler]

We checked with Visual Studio 2008 and do not have the problem. The video was shown nicely over several minutes. Therefore I have to admit, I have no idea.