Slow reaction to buttons

[IgorSivakov]

I have a bunch of embedded mimics, with one integer parameter. Every of the five elements on this mimics addresses to string array, gets name of the group and, via indirect tags, shows different properties of this group. Buttons up and down change parameter of an embedded mimics, so they show next/previous group. 

I have an issue - between pressing the button and reaction is big delay. Can it happens, because database handles this operations slow for some reason or my solution just cant work faster?

[AdamWoodland]

https://www.youtube.com/watch?v=En2eDubU_jI for anyone that embedded video is blocked for

It looks like the scripts the buttons are triggering are finishing quickly so it may just be down to the mimic refresh rate which by default is 1.5 seconds. You could try enabling fast update on the animations used to see if that improves things as it changes the update rate to 0.75 seconds (by default, changeable per client but not really a recommended thing) but as you're using indirect animations combining with fast updates will likely put a load on the server that might not be acceptable.

Worth a test though to see if that is the cause, and maybe the normal update could be tweaked down to 1.0 seconds or something that is suitable for your environment.

Check the help for more info on the fast updates, set per animation.

[BevanWeiss]

Somewhat as Adam has said, it's likely an issue with the indirect reference.

You could have a look in the Server Status tool and the OPC Subscriptions, to see that they aren't updating too frequently.

If you've got 'Shared with other embedded mimics' enabled wrong on your indirect animation items then you can end up with tag unsubscribe / tag subscribe events dozens of times per mimic 'scan'.. this will cause performance problems.

The other thing to do would be to have a look in the ViewX logs.  Start with a stationary ViewX on a different page, delete the logs, and then click on the mimic with your bad performance.  Check how much logging was created, and if it was out of control crazy, then you could try disabling the ViewX logging and see if that 'helps'.

If the logging is reasonable, then you could dive into it to see what some of the high frequency log entries are.. if you can work to reduce the number, or reduce the time taken for each then you'll improve the performance.