Problem occurs if the react function evaluates slower than the rate of events

[Cavtheman]

When giving the interact function a react function that is slower to evaluate than the time it takes for a new event to appear, new events flood the queue, meaning that the evaluation of new events get further and further behind.

The problem is also dependent on the speed of the system, e.g. some systems won't experience it while slower ones might.

An example would be the 10g reference solution: https://github.com/diku-dk/PoP/blob/main/referenceSolutions/2023/10g/AsteroidApp.fs

[cbrahe]

Note that while the example could be considered a bit extreme with 10 ms intervals, the problem also occurs at much lower rates.

While not the same problem, the issue also exacerbates the problem of new events blocking the firing of other events (e.g. holding down one, then two keys, will cause Canvas to lose track of the fact that the first key is still held down, as the events of the first button will stop firing, and there is no KeyRelease events)

@kfl

[kfl]

This is a known limitation of the current design.

I have no active plans for changing the design. So most likely this will remain unfixed.

I have considered throwing an exception if you are trying to set the timer below 17 ms, because that is a misuse of the API.

@Cavtheman please don't link to private repositories.

@casperbrahe please don't hijack this issue to report (what seems to be) another issue. I'm not sure I fully understand the other problem you are trying to describe. Can you give a small program that illustrate the issue? (In a new issue if that's relevant.)

[kfl]

@Cavtheman I think the issue could stay open. It highlights a problem with the current design, which should be addressed at some point. At the very least the limitation should be documented, and misuse of the API could also be handled better.

I'm just on the fence whether it's best to throw an exception or silently correct bad input, for instance by correcting interval with max interval 17 in `interact.

[cbrahe]

@kfl I'm curious how you got to interval 17 as the lower limit, as far as I can tell the issue does not appear on my desktop with interval 10 and maybe lower (running a i7-8700k), but on my laptop it appears at around 25 (i7-1355U).

@Cavtheman did you have an example not using TimerTick?

[kfl]

In lowlevel.fs we tell SDL to present synchronised with vsync to avoid tearing. Thus, 17 ms corresponds to a framerate of 60 fps (well, 16⅔ ms). But maybe your system refreshes at 120 Hz, thus you can go as low as 9 ms (technically 8⅓ ms).

If you want to see the problem, just use a slow function in react. For instance something like:

let slow halfSecs = 
    printfn "Yawning"; 
    System.Threading.Thread.Sleep(halfSecs*500); 
    printfn "Ready";;

[kfl]

Thus, a proper correction of the interval should take the framerate into account. But I'm not sure how to reliably query that. (And it makes the documentation much harder.)