Are you observing similar, long delays when running our sample app?
If so, please provide:
- The device model being used for testing: Settings->About phone/device->Model number
- Vuforia Engine SDK version
- The Unity Editor version (if applicable)
Additionally, steps to recreate the issue are also very helpful.
Some additional information below that you may find relevant.
Vuforia Engine Support
When the SDK Cloud Reco service is enabled, each camera frame is analyzed for two properties:
- A "scene change", which determines if what is in the the camera's field of view has changed, and
- Frame quality, which determines if an incoming camera frame is in-focus, exhibits no blurring and has sufficient lighting for recognition
If both of these conditions are met, then the SDK service will trigger a "query" to the Cloud Reco server. The server determines if elements of that query's camera frame match a target in the endpoint Cloud Database, and if it does then this triggers a "reco", which in-turn increments the reco count. Unsuccessful queries are not counted against the quota.
This SDK query operation is not normally presented to the application layer, thus it can be difficult to observe when a query is triggered during typical SDK usage. To better help developers understand the SDK's behavior, the Cloud Reco 'filter mode' was introduced in Vuforia 5: https://library.vuforia.com/articles/Solution/Whats-New-in-Vuforia-5. This functionality is intended for diagnostic purposes only, and is not recommended for use in production apps.
The updateSearchResult method accepts a "filter" setting value of either FILTER_NONE (disable filtering), or FILTER_CURRENTLY_TRACKED (enable filtering for targets being tracked) - with the latter being the default behavior of the TargetFinder. By default, Cloud Reco query results are not returned to the application layer for targets that are currently being tracked. If the FILTER_NONE argument is used, these results will be returned, regardless of whether the same target has already been enabled for tracking. The purpose of removing this "filter" is to enable developers to determine if reco event are unexpectedly occurring on the same target due to user behavior (normally due to a scene change due from inadvertent camera movement).
Additionally, inherent network latency can introduce race conditions in which more than one Cloud Recognition event would be logged at the portal. The following is one example:
- The user points the camera at a target in the Cloud Database, and a query is sent to the Cloud Reco service.
- The user moves the device slightly (with the same target still in the camera’s view), which triggers a second query being sent to the Cloud Reco service (aka a "scene change")
- The initial query is processed by the Cloud Reco service, and the service returns a successful reco result. The client handles the response before the second query response returns.
- The second query response is received at the client, but the first query has already been handled for this target. Thus, the client discards this result as a duplicate.
In the above example, both queries will be counted as successful recos on the Cloud Database.
Depending upon the use case, we normally recommend that the SDK Cloud Reco service be stopped after a successful reco. This will help to better control when a query occurs. A UX element can be introduced at the app layer if it is desired to trigger another query.