Whether 'frameprocessed' and 'persontracked' event should be merged.

[haoyunfeix]

tingshao:

This topic is triggered when discussing how to embed the rgb framedata in result.
‘frameprocessed’ is currently send per frame no matter whether there is actual person tracked.
‘persontracked’ is only sent when some person is tracked.
The event data of these two events are the same format, with exception that the data of ‘frameprocessed’ can be empty.

Choice 1: use options to config the results, using only one event:
add options in config to choose whether rgb data is needed and whether the event should be per frame triggered.

Choice2: this is PT’s current implementation: use two events, to let user dynamically add/remove event listener to make addon aware which event to send. While whether rgb data is carried is also configed in options.

Which choice do you prefer? or new choices?

huningxin:

I prefer to multiple events, it is straightforward for use case and flexible to compose.

The question here is it seems redundant to carry same data in multiple kinds of events, correct?

Could we introduce corresponding getters to query the data? The the events could be just notification for data ready instead of carrying any actual data. It would also benefit for performance due to less objects constructions for different events.

For example:

An app wants to display each frame and to be notified by person tracked:

> var frameData = new Unit8Array(size);
> instance.on('frameprocessed', function() {
>    instance.getFrameData(frameData);
>    ui.displayFrame(frameData);
> });
> 
> instance.on('persontracked', function() {
>   var trackedPersons = instance.getPersonData();
>   ui.displayPersons(trackedPersons);
> });

These getters could be synchronized as there would be no I/O operations. Implementation could make the data ready after emitting an event. So there will only be a object construction or a memory copy.

Here, getFrameData accepts an existing typed array object and fill the contents instead of returning a new object. It improves the performance by less object constructions (memory chunk allocation and free). getPersonData doesn't save much if using the filling pattern.

I am thinking whether we need to define persondetected and personnotdetected events, as PT has detecting and tracking states. If we have them, the pt_tutorial_1 would only listen to the two events instead of listen to the frameprocessed event. I will open another issue for discussion.

DonnaWuDongxia:
In this solution, do we have the requirement to match the frameData with the persontracked data? The handler is developer owned, we can't garantee that sync API can keep the allience as we always keep the latest sample and processed result in native world, right

huningxin:
Module can attach time stamp to data so JS code can match them if needed.

tingshao:
is it ok to getResult() which returns both framedata and its associated persontracking result?

huningxin:
For some use cases, like console samples, it doesn't need the frame data.