Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
A problem involving large data (~130,000 tracks) which included a large amount sub-data (multiple polygon annotations per track) was crashing during loading.
I narrowed down the problem to the fact that the
baseAnnotationStore
which is the basis for thetrackStore
andgroupStore
has a computed property calledsorted
which was passing around a direct copy of each Track. The sorted property was used to display tracks in the track list, the event timeline, and multiple other areas. Each time there may need be another computed property based on this list which may require eitherforEach
ormap
for all of the values.Initially I have changed the
sorted
computed property to not sort and create tracks until a call tosetEnableSorting
. For track lists that are < 20000 I've enabled it by default. For greater than it will be enabled once all cameras are loaded and ready. The intermediate sorting as groups of tracks were added were slowing down the loading process.I decided the remedy was to modify the
sorted
computed property to return only the data inside of Tracks/Groups that are needed. They happened to be theid, begin, end, confidencePairs
and a small functiongetType
which gets the current type of the annotation or returns 'unknown'. I created a new type calledSortedAnnotation
which has only this data available on it.This prevents bounds/geometry/attributes/features and all the data from being copied and passed around.
AnnotationWithContext
is another type which is based onsorted
so everything that usedAnnotationWithContext
needed to be modified to to useSortedAnnotation[]
The
BaseFilterControl
used two functions calledsetType
andremoveTypes
on the tracks themselves for when they were being edited. I moved those functions into the rootcameraStore
and provided them to theBaseFilterControl
. You will not that I have to wrap those functions in the Viewer.vue to maintain the properthis
context. You can see that in Viewer.vue this is done for theremove
function as well.useEventChart
had a section in the computed value where it would getmarkers
. Markers were an indication of a feature existing on aspecific frame or not. It happened to grab markers for all of the track data. The only time markers are used are when a track is selected for editing. I refactored this to use thegetTracksMerged
from thecameraStore
only on selected tracks. This reduces greatly the amount of information being passed around inuseEventChart
.I changed the
getType
that was typically referenced to make it return the string value instead of the confidencPair themselves. That's why in some location I removed the ending[0]
so it went fromgetType()[0]
togetType()
Finally the tests have been updated to reflect the new reorganization.