[RESOLVED] Processing Time For PVOID Into Byte Array Conversion

[Paul McKenzie]

I Already removed Paint and run my application. But no changes in the result.

The retrieval of the data from the card should do nothing except place the data onto the queue. Once the data is copied to the queue, that's it -- the reading of the card data is done. Instead, you're calling InvalidateRect and all sorts of other things during the reading of the data -- this is wrong.

The producer would do something like this.

while (forever)
{
    while (card_says_I_have_data)
       AddDataFromCardToBackOfQueue();
}

If it's anything more than that, you're not understanding the concepts that I've given you as well as 2kaud and Victor. You shouldn't be invalidating rectangles, putting together drawing buffers, etc.

On another thread (the consumer), you should then do this (this is happening "at the same time" as the code above):

while (forever)
{
    if ( queue_not_empty )
    {
       RemoveDataFromFrontOfQueue()
       DrawMyImageWithTheData();
    }
}

The while (forever) will quit at some time, either it is signalled that no more data will come in or by some other means. Of course, you have to use the proper synchronization between the consumer/producer threads so that the queue doesn't become corrupted. You could even "lock" the queue with the RemoveDataFromFromOfQueue (and even in this case, to make the read "fast", you only read at most, say 500 bytes at a time). Then when the Read is done, you, unlock the queue so that the producer (the card) places data into the queue.

If you don't understand the producer/consumer paradigm or do not understand what a queue is, just say so. It seems you're not quite getting why your method is flawed, and why I suggested that you should just scrap it and use proper techniques. Just copying data to an array in a "simple" loop from begin to end is not a queue. You can use an array as a queue (but not necessary as there is std::queue built for this), but unless you use that array correctly as a queue, you're not going to get anywhere.

A queue requires that you copy data to the back of the array, while the processing of the data uses the data in the front of the array.

As an example, let's say that the queue has room for 10,000 bytes. Then 2,000 bytes of data comes in from the card (the producer). You place this data in the queue, and at the same time, the drawing function (the consumer) is looking at the queue for any data -- it is not looking or even care what the card is doing.

So now let's say your drawing function has drawn 1,500 bytes of data, and then the card sends 2000 bytes of data. Your card reading thread takes this data and places the card data in the queue -- nothing is being overwritten, since the data is placed in the back of the line.

The queue had 9500 bytes of space since the drawing completed 1,500 bytes. At the same time, the drawing function finishes up with the remaining 500 bytes it had to do the first time, then it looks at the queue and sees that there are 2,000 more bytes of data, and then draws that data.

Let's say the drawing function now processes 1,999 bytes of data, and then the card sends another 2000 bytes of data right when the drawing program is going to draw the last byte. You place the new card data at the back of the queue (which can hold 9,999 bytes, since the drawing processed 1,999 bytes). The drawing function finishes drawing that last remaining byte, looks at the queue, and sees it needs to draw more data.

This producer/consumer interaction goes on forever, until the drawing ends. Do you now see that you never miss any data, provided that the queue is big enough? Do you see where your current method fails miserably? Do you see why having the fastest code in the world doesn't matter with using a queue? With your current method, all of the times when the drawing function didn't draw all the bytes, you got into trouble. With the queue, you will never get into trouble (and your function to draw doesn't even need to be fast, albeit it is good that it is fast).

First I used Timer. called at every 1 milli seconds. This case I missed 15 to 20 lines. So I go to threads.

Threads are not going to help you -- you need to use the proper data structures, and you're not doing it. If you used the proper structure, it doesn't matter what the timings are.

TempRealDataArray[i] = (*(bTo + i)); //This array data passed to paint method to drawn an image.

There should be no drawing at all, or even mention anything about paint methods. This is the time where you place the data onto the queue and return.

if(i == 1030)[B] Temp[cnt] = TempRealDataArray[i];	 //To find the missed lines. 
                                                                              // Temp[] stored the single data per line and print a file after

GetDlgItem(IDC_TIMEDIF)->SetWindowText(str);		//Takes 1200 to 1500 micro seconds

And if it took 10,000 microseconds, then what do you do? What should be happening is that this painting routine doesn't care one bit about the timing, as long as the queue has room for more data coming in from the card. If the drawing routine takes a long time so that the queue is too small, then make the queue bigger -- that's how you fix the problem. You don't fix it by trying to write the fastest code in the world.

Mistake is in my side. But sure I tell Painting & the compiler's optimizer not reason for this. B'cos I removed paint method and run my code and also run my application with higher configuration PC.

Again, forget about what the compiler's optimizer does, and forget about how fast your PC is, and honestly forget about QueryPerformanceCounter() -- pretend that function doesn't exist. None of those things would hardly matter if you coded using the proper data structures.

My first aim is getting the data correctly from camera with out any missing data.
If I achieve this then my problem solved 90%.

If you took the advice of creating a queue, then 100% or close to it would be solved.

Pls take me at right path.....

We are trying, but are you listening? So far you're still stuck on using the same broken design. Again, forget about what you wrote -- it won't work if you do not want to miss any data.

My feeling is that you're trying to code in a "simple" fashion instead of actually coming up with a design. The card has data, you draw the data to the screen, and if the data comes in too fast, you create the drawing code even faster. Sure, that's the easy way to think about it, and frankly any beginner would have done exactly what you've done. But it isn't correct and it is seriously flawed. You have to actually use certain design patterns to overcome the problem.

Regards,

Paul McKenzie