Bug introduced in V10.4 or earlier and persists through V12.0

A support case with the identification [CASE:3726810] was created.

[...] It does appear as though UpdateInterval is not working well with MousePosition. As such I have gone and filed a report with our developers so that they may further investigate the issue. [...]

Dynamic[MousePosition["GraphicsScaled"], UpdateInterval -> 1, 
 TrackedSymbols :> {}]

Dynamic[CurrentValue[WindowSize], UpdateInterval -> 1, 
 TrackedSymbols :> {}]

Graphics @ Disk[]

Whether you move over a disk or resize the window, Dynamic is updated at a high frequency, way more often than once per second.

Should this be considered the expected behavior?

Is there any work around?

  • 1
    $\begingroup$ I would not have expected such a behavior. Even using UpdateInterval -> Infinity or the typical encapsulation inside Refresh doesn't seem to prevent the updating from being continuously. $\endgroup$ – Karsten 7. Sep 28 '16 at 21:49
  • $\begingroup$ you are saying that this was introduced with 10.4. or earlier, have you any indication that this ever was different? I just have tried version 9 and 7 and both showed basically the same behavior. So I think it most probably never has been different... $\endgroup$ – Albert Retey Oct 4 '16 at 10:40
  • $\begingroup$ @AlbertRetey I think so, yet I don't know what is the header's convention in such case :) Feel free to rephrase it. $\endgroup$ – Kuba Oct 4 '16 at 10:42

We can setup an extra switch (flip) to control whether the mouse is tracked or not:

flip = -1; posCollect = {};
        If[flip > 0
            , If[# =!= None, 
                        posCollect = Join[posCollect, {{AbsoluteTime[], #}}]] &[
                MousePosition["Graphics"]]; flip = -flip
            , Inactive[MousePosition]["Graphics"]
    flip = -flip
    , UpdateInterval -> 2, TrackedSymbols :> {}

To make it more responsive, we additionally trigger the switch as soon as the mouse enter the Graphics:

 Graphics[Circle[], Frame -> True]
 , If[CurrentValue["MouseOver"], flip = 1]

To verify that we did restrict the sampling frequency, we plot the sampling time gaps:

posCollect[[;; , 1]] // Differences // ListLinePlot

sampling time gaps

The gaps shorter than 2 seconds came from my mouse quickly repeatedly re-entering the Graphics.

  • $\begingroup$ Nice, I think this is a fix I need. $\endgroup$ – Kuba Oct 4 '16 at 9:20
  • $\begingroup$ @Kuba Glad you like it :) BTW. if it were me, I might also try localizing flip with the DynamicModule wormhole trick. $\endgroup$ – Silvia Oct 4 '16 at 14:50

This is not really an answer, because it involves speculation on my part. However, I think it casts some light on the issue you are reporting.

Consider the following extension of your code:

x = 0;
Dynamic[Row[{x++, "  ", MousePosition["Graphics"]}],
  UpdateInterval -> 2, TrackedSymbols :> {}]
Graphics @ Disk[]

Note that, as long as the mouse cursor is not in the graphics output, x updates at the specified interval of approximately once every two seconds. When the mouse cursor moves onto the graphics pane, the situation changes and both x a the mouse position numbers are updated at the rate mouse evens are processed. This suggests that event tracking overrides any user specified event update rate. I think this is reasonable design decision. When one is tracking events, one wants to get them as fast as possible in order to react to them promptly. Otherwise, event handling would becomes distressingly sluggish.


Here is code that might provide a work-around for you. I must admit I do not understand why you want this sluggish behavior.

DynamicModule[{t0 = AbsoluteTime[], p, q = None},
   p = MousePosition["Graphics"];
   If[Mod[Round[AbsoluteTime[] - t0, .1], 1] == 0, q = p, q]]]
  • 3
    $\begingroup$ +1 for a work around but notice that tracking events and displaying associated data are two different things. I'm glad that MousePosition is in general responsive but I don't see why this should prevent me from displaying it only once per second. Moreover, even with workaround that Dynamic is triggered non stop which is obviously something to avoid if possible. $\endgroup$ – Kuba Sep 29 '16 at 6:15
  • $\begingroup$ @Kuba. I don't follow your reasoning. The front-end must track user interface events like mouse movement or window resizing whether or not you have any code that explicitly queries for these events. Updating your query each time it gets a new event is probably less costly in processing time that making a test to see whether or not it should skip your query. $\endgroup$ – m_goldberg Sep 29 '16 at 12:43
  • $\begingroup$ Yes, except that I don't think your last sentence is correct. FrontEnd is not checking continuously whether it should be displayed. It knows at the beginning that it should be updated once per second, like a scheduled task. I'd be surprised otherwise. What was wrong then? TrackedSymbols:>{} should point that FE should not care about any symbols, it somehow misses CurrentValue and friends which makes dependency tree not empty and those updates happen. More or less, I don't know details of course. $\endgroup$ – Kuba Sep 29 '16 at 12:53
  • $\begingroup$ @Kuba. Perhaps you know more about how the front-end handles UI events internally than I do (I know only a little), but my front-end experience does not seem to support your position. It will be interesting to see what response you get to your tech support case. I hope you will report that response here. $\endgroup$ – m_goldberg Sep 29 '16 at 13:05
  • 3
    $\begingroup$ @m_goldberg: I think it is pretty obvious that the WindowSize case is relevant: if you have a complex user interface and want it to adjust to window size changes you will often find that updating continuously is not what you want - even not very extreme cases will cause the Mathmatica frontend to become very slow or even crash. If you try to write more complex interfaces it turns out that the lack of more control over the dependency tree - or at least a possibility to check what it is - is a serious limit as it is quite difficult to control how often the various Dynamics will update... $\endgroup$ – Albert Retey Sep 29 '16 at 14:46

I found that FrontEnd`$TrackingEnabled can control the tracking state of CurrentValue and MousePosition, for example

Dynamic[Block[{FrontEnd`$TrackingEnabled = False}, MousePosition[]], UpdateInterval -> 1]

I believe this is the easiest way to solve the problem.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.