12
$\begingroup$

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?

Improve this question
$\endgroup$
3
  • 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$
    – Karsten7
    Sep 28, 2016 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, 2016 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, 2016 at 10:42

3 Answers 3

Reset to default
6
$\begingroup$

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.

Update

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},
  Dynamic[
   p = MousePosition["Graphics"];
   If[Mod[Round[AbsoluteTime[] - t0, .1], 1] == 0, q = p, q]]]
Improve this answer
$\endgroup$
6
  • 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, 2016 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, 2016 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, 2016 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, 2016 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, 2016 at 14:46
6
$\begingroup$

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

flip = -1; posCollect = {};
DynamicWrapper[
    Dynamic[
        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:

DynamicWrapper[
 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.

Improve this answer
$\endgroup$
2
  • $\begingroup$ Nice, I think this is a fix I need. $\endgroup$
    – Kuba ♦
    Oct 4, 2016 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, 2016 at 14:50
4
$\begingroup$

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.

Improve this answer
$\endgroup$
3
  • $\begingroup$ A great answer. $\endgroup$
    – user69323
    Mar 27, 2020 at 9:44
  • $\begingroup$ Thank you for this answer. How did you find this variable? There is apparently no documentation about it. $\endgroup$
    – Qbyte
    Feb 1, 2021 at 19:38
  • $\begingroup$ This was exactly what I was looking for! I have two large graphics that are slices through a 3D volume. I track my mouse position on one, then plot on the other based on the position. With large graphics it became really sluggish. Setting an UpdateInterval to 0.25 makes it work perfectly. Many thanks! $\endgroup$
    – atlasgeo
    Apr 23, 2021 at 18:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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