Issue using frame grabber in Windows 10

[richferrara]

My software team has a 64-bit LabWindows application that captures radar video through a Foresight Imaging Accustream Express 170 frame grabber card. We show the live video in an Active-X control on our display using DirectDraw, then use Windows functions to draw an overlay on top of it that contains some of our own symbols to represent the helicopter, tracks, land/sea map, etc.

Our application was using 64-bit Windows 7. We are now trying upgrade all our PCs to Windows 10 and running into an issue where the overlay no longer works. Every time the frame grabber captures a new frame of video, all our symbols are erased.

Foresight tech support told us that the issue is Windows 10 no longer supporting DirectDraw, and that our application would have to handle reading and displaying the image manually instead of going through Active-X. The information that I've found online on this topic is confusing.

Can anyone shed light on how we can fix the problem? Is there a way to get around this or do we need to look into using a different frame grabber?

[rolfk]

While DirectDraw/Direct3D might be disabled by default under Windows 10 (it is not on my machine) it still can be enabled (but should be considered a workaround as this is sooner or later going to be removed). Microsoft nowadays wishes they never had come up with the DirectXXXX technologies which are a nightmare to secure.

Try to run dxdiag.exe and see what it reports for your displays. If DirectDraw is disabled you should be able to enable it for the display in question (if your video card driver supports it).

But overlays on top of driver drawn surfaces is a real difficult thing to support. The proper thing would be to grab the image data from the grabber instead, and impose your own overlays on top of that. It's a lot of work to do but avoids the problem of having the driver try to shove its data under your overlays without destroying the overlays.

[richferrara]

I've run dxdiag and it reports that DirectDraw acceleration, Direct3D acceleration, and AGP Texture acceleration are all enabled.

The basic scheme we're using is:

• We initialize the frame grabber card and start displaying continuous live video in the Active-X control using the DirectDraw renderer.
• We get a Windows handle (hwnd) to the Active-X control by calling a function in the frame grabber SDK library.
• Once per second, we run a routine triggered by an asynchronous timer that uses Windows SDK functions to draw our overlay symbols in that hwnd.

[rolfk]

I do understand what you are doing. It's pretty much what I expected.

But my solution would be to rearchitect the whole thing. That ActiveX control was an easy workaround for the problem at hand.

The proper operation would have been however:

- accessing the frame grabber API to get the actual image data from the frame grabber. This most likely involves dealing with camera specific image data formats, including pixel format, scan line length which is often different to the actual width * pixeldatasize value, width and height of the image.

- Once you get that image create a format of a pixmap that works best for the plotting of the image to your screen. In order to easily support overlay data IMAQ Vision would be a good option although it may be not as trivial to get things like plane symbols etc. into the overlay, depending how those symbols must look.

- Then put the overlay data into the image and display it in an IMAQ Vision control.

If you want to avoid IMAQ Vision you have a lot more work to do as you must perform the overlay function yourself, likely by redrawing it everytime you plot the image to the screen.