Perspective: Capture mouse stopped event. Increase binding refresh rate. What determines binding refresh rate?

I am trying to determine when the mouse has stopped moving. It looks like a typical solution is to reset a timer on mouse move. Anytime the timer reaches done the mouse has stopped moving. I have implemented this method using view custom properties (see below), however the binding refresh rate is too slow and the state detection takes anywhere between 500 - 1000 ms (approximately). This is too slow and variable for a responsive design.

  • I wanted to find out more about what controls this binding refresh rate, and whether it can be lowered
  • I have thought about using the component.refreshBinding() function but haven't figured out a useful trigger condition
  • I've looked into timer.sleep() and later.py but the information relating those two options to Perspective is unclear to me. Does later.py work in perspective?
  • I also saw mention of java.util.Timer

With these options, I do not understand how multi-threading works in Perspective. I have implemented the system.util.invokeLater() function in Vision before, but I do not know what is appropriate for Perspective.

The implementation I currently have is:

# onMouseMove
nowDate = system.date.now()
now = system.date.toMillis(nowDate)
self.view.custom.target = now + 50
# expression binding on self.view.custom.mouseMoving
toMillis(now()) < {view.custom.target}

This is an extraordinarily bad idea in Perspective. All scripting is on the gateway, so you are relying on lots of messages between the browser and the gateway to track this. :frowning_face:

Taking a step back, what are you ultimately trying to do with the information about (presumably) what component the user is dwelling on?

The purpose was to reduce the number of times I run a hit detection method on a large svg layout. It seems I can't put listeners on individual svg elements at this time, and there was really no other way to meet customer specification. So I've implemented my own svg viewer with pan/zoom and hit detection for highlight and pop-up.

Thank you for the perspective Phil

To that end, there does not seem to be a problem right now with running the hit detection on every mousemove event. I was just worried about using up available resources in the application. Would you have any advice about resource management in perspective?

All scripts executed by Perspective are submitted to a (by default) unbounded thread pool with a time-to-live of 60 seconds; meaning threads are generated as-needed, and will be recycled if more work gets to them before their 60 second idle expiration. This can cause issues, because obviously more sessions -> more scripts -> more threads -> more load on the gateway. You can opt in to a bound thread pool, which would cap gateway CPU/memory usage at the expense of it possibly taking longer to execute scripts:
https://docs.inductiveautomation.com/display/DOC81/Gateway+Configuration+File+Reference#GatewayConfigurationFileReference-PerspectiveThreadpoolRestrictions

1 Like

Thank you, I'll look into this once I have a full load test ready.