We are using multiple instances of the ImageViewerControl at the same time. We have use cases where multiple ImageViewerControls will fail to display video and will show a black screen. This occurs for both live and recorded video.
Is this a known issue and is there any documentation for preventing this from happening?
We are reusing the ImageViewerControls instead of disposing and reinstantiating when providing new cameras to be displayed.
Our code for doing this involves calling Disconnect(), setting CameraFQID, calling Initialize() and Connect() for multiple ImageViewerControls. After all the ImageViewerControls have been updated to connect to a camera we make a single call to EnvironmentManager.Instance.SendMessage to explicitly have it do a ModeChange to ClientLive.
In an another control with the same issue it is doing the same sets of configuring multiple ImageViewerControls to connect to a camera. After they are all set we make a single call to use a PlaybackController’s SetSequence to loop video.
We’ve somewhat mitigated this with some throttling (~250-500ms) to prevent sending instructions to the ImageViewerControl as frequently but we can only throttle it by so much due to some requirements. Most but not all of the ImageViewerControl at random still goes into a black screen despite the throttling if the number of times to change the camera is increased.
Repeatedly calling Initialize() and not calling Close() will lead to leaking. Initialize and close should go hand in hand.
ImageViewerControl utilize hardware acceleration, we have seen often that graphics drivers that were old and not updated has caused leaking, crashes or other issues, this has been true for both Smart Client or MIP SDK based application using the ImageViewerControl.
Historically there has been issues, please make sure you are developing using the newest MIP SDK to ensure you have the newest updates and fixes pertaining to this.
If this does not directly solve the issue could you please meassure whether your app is leaking (memory, handles, threads).
Please confirm that the statement about Close() must be called after Initialize() implies that ImageViewerControls cannot be reused and requires constructing a new ImageViewerControl instance per Camera.
According to the Diagnostic window (using EnvironmentManager.Instance.EnvironmentOptions[EnvironmentOptions.PlayerDiagnosticLevel]) it reports Hardware acceleration: Intel.
The testing has been done on computers using an Intel(R) HD Graphics 530 with driver 26.20.100.8142 which was updated from 20.19.15.4531 on October 12th to resolve memory leak issues.
We are working with the 2020 R2 version of the SDK.
Additional testing has shown that streaming higher resolution and fps cameras will cause memory and threads to rapidly rise. This is an increase of ~200mb to ~2.5gb and ~90 to ~1200 threads on a user control utilizing 9 ImageViewerControls.
It would be speculative to answer as this is not a known issue. If the issue happens in two clients at the same time I would suspect the Milestone server/services to be the cause, if not I would expect the ImageViewerControl or local SDK environment.
No. Again speculative, but there is no status achievable from the ImageViewerControl itself, while status of the Milestone server/services could be achieved.
General advise:
It is critical to have the drivers for the graphics cards in your test PCs up to date. We see many issues of Smart Client or ImageViewerControl based client application leaking or malfunctioning in other ways and a graphics driver update makes the issue go away.
I think you should make a measurement whether your application leaks, with the description at hand I strongly suspect it is still leaking even if the re-use of the ImageViewerControl have been corrected.