fix bug in Viewer syncer loop #9222
Conversation
| @@ -2114,7 +2114,8 @@ namespace rs2 | |||
| try { | |||
| s->start([&, syncer](frame f) | |||
| { | |||
| if (viewer.synchronization_enable && is_synchronized_frame(viewer, f)) | |||
| // The condition here must match the condition inside render_loop()! | |||
| if( viewer.synchronization_enable ) | |||
There was a problem hiding this comment.
I understand the fix but I don't understand the regression cause, do you?
There was a problem hiding this comment.
I got here by debugging it. I noticed that we get IR frames that are somehow not answering the is_synchronized_frame() call (the return is false). Following the logic with Evgeni's help, we saw that the render_loop() checks the syncer but we didn't push to the syncer...
So we have someone pushing to a frame queue on which we do not wait, instead waiting on a syncer that gets no frames. And we know that a syncer that does not get any input has no output! So we just wait. And nothing happens.
My guess is that the concurrency work has simply made this come out, whereas before something didn't work. Or maybe it's the other way around... but this fix definitely makes more sense, and the problem goes away with it.
(cherry picked from commit 716d310)
Found by Nir during sanity checks:
Switching to IR in 3D texture source froze the view.
The render_loop() depends only on
synchronization_enablebut sometimes we bypass it and so it cannot get the frames...Tracked on [LRS-116]