This did not happen in earlier versions of the eyeX SDK. This has no bearing on the Gaze SDK for Rex, or Analytics SDK which doesn’t even work with the EyeX.
Lets burn more time on this…
when the HandleEvent function is called, and the event type is determined to be TX_BEHAVIORTYPE_EYEPOSITIONDATA, we were instructed to process it as follows:
if (txGetEventBehavior(hEvent, &hBehavior, TX_BEHAVIORTYPE_EYEPOSITIONDATA) == TX_RESULT_OK) {
OnPositionDataEvent(hBehavior);
txReleaseObject(&hBehavior);
}
The OnPositionDataEvent function gets the eyeposition information by the following method:
if (txGetEyePositionDataEventParams(hPositionDataBehavior, &eventParams) == TX_RESULT_OK) {
}
here, the eventParams.RightEyeX and eventParams.RightEyeY return invalid values, for no apparent reason.
Specifically, they will be both set to a value such as -9.2559631349317831e+061
While the LeftEyeX and LeftEyeY values will be set to acceptable values corresponding to the range of pixels found in my display.
The EyeDetection Indicator widget shows both my eyes are detected properly.
Regarding the asynchronous problem… I can’t provide you with exact details yet, however I can say this much. It is logical that for each gaze coordinate their is an eye position value. That would be necessary to render the location of the eyes and gaze simultaneously. It seems that the SDK is designed to deliver these parameters asynchronously, and therefore can not guarantee that there is an eye and gaze coordinate for each sample. In fact, I believe that the HandleEvent function can be called by an eye position event while it is still processing a gaze position event. That is likely to be the problem. This did not happen in earlier versions of the EyeX SDK.
It is particularly frustrating and a huge time drain when SDK upgrades break existing functionality and force developers to reprogram previously working code for ostensibly no good reason! Please do not release SDK updates until you have tested and retested every single unit, and do not deprecate functions every time there is an update. I am neither interested in refactoring function names just because your developers thought of a better naming convention, nor of posting these rants online.