juliena82
commented
8 years ago Yes das ist genau das! Before, there was only one thread, the GTK GUI thread. And the video processing was made on a basis of 4 frames by second only, so as too keep the GUI responding (and yet, if you tried video processing on one of the cascade démos, you might have had some surprise). Now there are 3 threads:
- Always the GTK thread (GUI)
- A thread for video decoding
- A thread for image processing (executing the OpenCV code of the demo)
That way, the video processing can be proceeded at maximum of either available frame rate or CPU capacity, while the GUI is still responding.
Moreover, it opens to pipeling of Video decoding and image processing: it's not done yet, tought it's very easy to do, because I don't think it is a necessity for the demonstrator and also video decoding is quite fast compared to most of image processing functions.
However, if in the future we want to enable chaining of different filter / image processing, then it will be important to pipeline the processing. But it's in the long term...
valera-rozuvan
shervinemami
Hi @juliena82 ! I guess it's your recent changes to how the application uses threads... Now when I use video feed from my web cam, and turn on some OpenCV filter - I don't see any lag in the output video!!! Congratulations = )
Am I right with my assumptions?