We have several “ImageViewerWpfControl” controls in use in our application. Unfortunately, when the network and application are under any load, the application will briefly hanging initializing an ImageViewWpfControl with a camera feed.
Is there anyway we can (either should work):
-
Make the initialization/connect code for the ImageViewerWpfControl non blocking such that it will continue its initialization behind the scenes but return as soon as possible to not cause any visual delays in the application. We speculate the network calls are occurring on the calling thread (i.e. the applications UI thread)
-
Allow the control to be initialized/interacted with by a separate STA marked thread. Currently if we do the controls initialization/connection on a separate STA marked thread, your internal code is calling back on the Applications Main dispatcher thread, causing a crossthreading exception with the control. Can we provide an STA marked thread in the SDK initialization process to be designated as the Dispatcher you use internally?
As the ImageViewerWpfControl is currently implemented you cannot do either.
I would like to understand to what extent you see an issue? Is there a situation where this hanging becomes very visible?
Milestone uses the same control in the Smart Client and we are not aware of a problem. When you see this brief hanging, might you see it in the Smart Client in the same way? (Or is your application different in a way that might make it stand out?)
I believe once the video initializes and is playing it is fine and you won’t notice it when pulling up additional video. However, when there are other animated objects on screen, you see the freeze occur because the UI thread is briefly held up in initializing the control. The network we are on is under quite a bit of load at all times, which I believe is contributing to the problem. When we are on our local network in the office, the video comes up fast enough that no pauses are noticed.
I asked around in Milestone Technical Support, the feedback is that we do not see UI freeze (not enough at least to notice). Now the experience is with Smart Client of course, but we do not have different methods, so it should be the same for your ImageViewerControl and that of your application.
I do not know if you have tested or if it is feasible to test. Can you observe the same freeze using Smart Client?
Sometimes we test in our test environment simulating loaded network or similar. We use Clumsy https://jagt.github.io/clumsy/ for this. If you can reproduce the issue in your test lab using Clumsy I would like to know, and know what settings.