Unsolved Call back function problem
-
Thank you for the answer.
Do not think, what make it global will work. Camera is producing 20fps. In this case, i will not have exception, but it is a chance, what it will be overwritten by next frame, before i can use it.
I have already working solution, where i am allocating memory in call back function and destroying in StreamBuffer. I found it bad. Is`t it?
Just let me know, if you need more information. -
@Mikl said in Call back function problem:
I have already working solution, where i am allocating memory in call back function and destroying in StreamBuffer. I found it bad. Is`t it?
Just let me know, if you need more information.I actually worked with cameras from Point Grey as well, and we did allocate the frame each time data was retrieved. I know this looks ugly, but we did not find any smarter / faster solution (I'm not telling there are none). This even becomes trickier with multithreading...
-
@JohanSolo
It is a BIG chance, what my app will run during days. Recording, playback, network communication, ...
Want to make it as "perfect" as possibleIs Smart pointers can be a solution?
May be i need to make wrapper around IpCamera class?
.....Sometimes i missing garbage collector with dcnew keyword from .NET.
-
@Mikl said in Call back function problem:
Is Smart pointers can be a solution?
Yes, this can be very handy. We basically did this.
-
@JohanSolo
Smart pointers can be a solution, but it will overload my functions. I was trained to write code so, what next developer after me will be maniacal serial killer, who know my address. And i believe in karma. Next reader will think about me "what a sh@t?". And i don`t like this.void IpCameraBlackFly::OnNewFrame(DeviceFrame* frame) goes to void IpCameraBlackFly::OnNewFrame(QWeakPointer<DeviceFrame> frame)
Another solution, is to pass object. Not pointer. Yes it will be one extra copy done by system (time + memory), but i can be sure, what will not have memory access error. who care in our time about 2Mb and 200 cpu tics? Not really elegant and optimal, but safe.
-
@Mikl said in Call back function problem:
Another solution, is to pass object. Not pointer. Yes it will be one extra copy done by system (time + memory), but i can be sure, what will not have memory access error. who care in our time about 2Mb and 200 cpu tics? Not really elegant and optimal, but safe.
That sounds reasonable to me. As long as the extra time for the copy is not a problem this is the easiest I'd say.
-
@JohanSolo
Heh! You never know...
Do you know how it is happening?
You developing safe app on nice new laptop. Demonstrating to your boss. He is happy.
Next month you see him using in on 40fps with 1024x900 on 11'' 6 year old netbook. Blaming you, what it is too slow. -
@JohanSolo
I did modifications in a code and now passing object. It looks more simple and brings less problems. No need to delete pointer after usage, no worries about memory access,...But, speed test, using QueryPerformanceCounter, schowing, what is it 1500 times slower, comparing passing pointer. 1500 ticks instate of 1.
Question is "what is 1500 ticks"? Should i worry about it? Can i speed it up?
My copy constructor is
DeviceFrame(const DeviceFrame& original) { Copy(&original); } void Copy(const DeviceFrame* original) { if(Frames != nullptr) delete Frames; Type = original->Type; Size = original->Size; Count = original->Count; Time = original->Time; Frames = new unsigned char[original->Size]; memcpy(Frames, original->Frames, original->Size); }
-
@Mikl said in Call back function problem:
I did modifications in a code and now passing object. It looks more simple and brings less problems. No need to delete pointer after usage, no worries about memory access,...
But, speed test, using QueryPerformanceCounter, schowing, what is it 1500 times slower, comparing passing pointer. 1500 ticks instate of 1.
Question is "what is 1500 ticks"? Should i worry about it? Can i speed it up?
IIRC 1 tick is one millisecond, therefore you're running at 0.6 Hz. There should be a macro which performs the conversion number of ticks to seconds.
My copy constructor is
DeviceFrame(const DeviceFrame& original) { Copy(&original); } void Copy(const DeviceFrame* original) { if(Frames != nullptr) delete Frames; Type = original->Type; Size = original->Size; Count = original->Count; Time = original->Time; Frames = new unsigned char[original->Size]; memcpy(Frames, original->Frames, original->Size); }
I don't see how there a way to speed up this, unless if you precallocate a bunch of frames in a circular buffer. What is the typical size of a frame?
-
@JohanSolo said in Call back function problem:
IIRC 1 tick is one millisecond, therefore you're running at 0.6 Hz. There should be a macro which performs the conversion number of ticks to seconds.
Are you sure about "millisecond"? It means, what copy is taking 1.5 sec.
http://superuser.com/questions/101183/what-is-a-cpu-tickI don't see how there a way to speed up this, unless if you precallocate a bunch of frames in a circular buffer. What is the typical size of a frame?
Bad news. Frame size is set from UI. No "typical" size. It is a "maximum" size. Depending of camera spec. But i will "eat" huge amount of memory for wining couple of ticks.
-
@Mikl said in Call back function problem:
Bad news. Frame size is set from UI. No "typical" size. It is a "maximum" size. Depending of camera spec. But i will "eat" huge amount of memory for wining couple of ticks.
Well, you could only reallocate if more memory is needed (and "waste" extra memory if the frame is smaller than the allocated area).
About the tick duration: I might have mixed up with the CLOCKS_PER_SEC (I'm not an intensive user of the windows API). The 1 ms was just a (apparently wrong) guess.