Josiah14
asked on
Data passing
I'm working on a DLL which will serve as the back end or engine for an arbitrary Win32 GUI front end to connect to. My back end should have no graphical code, of course. What I'm making is an interface for a camera-like device. This device has an SDK I'm using which utilizes CALLBACKs. Through several of these callbacks, which run in their own thread, I receive an image (as an object) from the camera device. I need an efficient way to forward this image to the Win32 GUI developer without exposing him to the SDK's callback functions. This image must be immediately forwarded because the Win32 Developer may want to display it the moment it is received, as these images are continually streaming from the device. (Ultimately, if you were to display the images as they came from the device, what you would get is a video in real-time of the images being captured by the device).
I'm not asking anyone here to solve my problem, but, as an entry level coder, I would like input as to what my options are and what the pros and cons are to each solution. I am concerned with speed.
I'm using MS VS 2008 on Windows XP to write the DLL in C++. The SDK is a DLL and static LIB written in C using an unknown compiler. I don't know how relevant that info is, but, there it is.
I'm not asking anyone here to solve my problem, but, as an entry level coder, I would like input as to what my options are and what the pros and cons are to each solution. I am concerned with speed.
I'm using MS VS 2008 on Windows XP to write the DLL in C++. The SDK is a DLL and static LIB written in C using an unknown compiler. I don't know how relevant that info is, but, there it is.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Perhaps I should clarify, the device is a camera, but it is continually taking pictures. Part of the objective is to allow the GUI to catch the streaming images from the device to make a sort-of 2D animation of what the camera "sees" in real-time. This is the real difficulty at the moment, for taking the image from the camera and throwing it out to the GUI in an object is as simple as a regular method call, but I need to be able to give the GUI a way of knowing when the image is available so every time the camera produces the image, the GUI has the option to display it. Outputting the image to the file system will not work as it will certainly be too slow.
I had considered using callbacks, but had not considered writing to shared memory. Since the GUI will have a WinProc anyway, this could be a good method. For what we want to do, the user has to explicitly make a call for memory cleanup already, so I could just throw that in with the device object cleanup. I dunno if actually writing the image data to a file in shared memory would be too much overhead, though... Something for me to consider.
I had considered using callbacks, but had not considered writing to shared memory. Since the GUI will have a WinProc anyway, this could be a good method. For what we want to do, the user has to explicitly make a call for memory cleanup already, so I could just throw that in with the device object cleanup. I dunno if actually writing the image data to a file in shared memory would be too much overhead, though... Something for me to consider.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
This is great. There's some applicable suggestions here that I never would have thought of.
I would start by dumping the output to files to see if that works. If it does, how quickly can files be constructed? Is that fast enough? If so, your GUI Developer could just be told that the sequence of files is held in the image dump directory, the file names are in sequential order. Last thing you want is for the GUI app to hold the data requester from firing, which would result in lost data.