(timer) is inaccurate and doesn't pause (not sure why either of those are the case)
(current [time in milliseconds v]) also still goes up when the project pauses, and worries me because i imagine a project breaking when daylight savings hits, or speeding up/slowing down when ntp starts syncing the time
i'm not satisfied with the available workarounds for detecting pausing in Timer problem either, it stops working if there happens to be a lag spike or even worse if there's a low framerate, completely stop the project. when a pause is detected it's also not accurate to when the pause happened.
i want to have enough precision to be able to tell how far audio has played, for things like rhythm games. this needs enough precision that adding or removing a couple frames can be a large issue.
personally i feel like (timer) should have at least millisecond precision and pause when the project is paused. the way i think of it it should have similar use to the wait block
i've heard only vaguely about the behavior being "locked", i don't see why it should be. if old projects need to be supported it could be polyfilled (snap could automatically convert it to a custom block that has the same old behavior with the new blocks, or just make it a hidden block called (legacy timer))
ideal implementation would almost definitely be performance.now(), even if a browser reduces the resolution of it by a significant amount, it would do the same to Date, and likely have other security measures that wouldn't make playing snap projects possible anyways. i don't think there's any mainstream browser where performance.now() is unusable by default
CURRENT TIME IN MILLISECONDS reports the current time, same as your cell phone does even if it's been turned off since the last time you asked. Its value is independent of anything you do in Snap!, or anything you do, period. That's how it should be.
TIMER is something we could negotiate about. Currently it is based on Date.now() as provided by the browser (minus whatever the value of Date.now() was the last time the timer was reset). Using performance.now() might improve the resolution, but it says here that browsers may reduce the resolution to units of 100ms as an anti-fingerprinting measure, so you might not get the benefit you're hoping for.
You are actually asking for two different features. One is to improve the precision of the timer. I don't think anyone would object to that as long as we didn't change the units (namely seconds) in which the timer is presented. But it's much more controversial to ask that the clock be stopped when the project is paused. First of all, as Jens keeps reminding me, Snap! never stops running. After a project is paused, a new script can be triggered by some event.
But also, people often use TIMER to time the reactions of the human user, rather than to time the running of a program. I don't see why your use should have priority. IANJ but I think you might do better to ask for a WHEN I AM [PAUSED] comparable to WHEN I AM [STOPPED], which would allow you to construct your own pausable timer. Well, I guess you'd also want WHEN I AM [CONTINUED].
Yes, I believe that's correct. Computers used to keep (internal) time in the current time zone, in my youth, and sure enough things broke across the shift out of daylight savings time. But nowadays it's all GMT. (I know it has a new name but I can never remember it. Sorry.)
But it's much more controversial to ask that the clock be stopped when the project is paused.
fair enough, i rushed this post a bit while i was slightly annoyed, sorry about that
in that case i think a set [timer pause v] to <> sensing block would make much more sense, i think it would fit in there quite well and wouldn't cause any incompatibility
CURRENT TIME IN MILLISECONDS ... [is] how it should be.
absolutely, my only issue with it is that it doesn't make a particularly good timer considering how much more likely it is to change in unexpected ways, and shouldn't be a workaround for an accurate timer.
browsers may reduce the resolution to units of 100ms as an anti-fingerprinting measure
that's mainly from firefox resist fingerpinting feature, snap wouldn't work AT ALL with that. it completely shuts down all sorts of canvas features, puts the same restrictions on Date, etc. it's not something that should be considered an issue for snap.
Interesting. I run Firefox in Strict mode, in which it claims to block fingerprinters. I don't see a specific option for reducing the clock precision but I should think "block fingerprinters" includes that. And Snap! runs just peachy. :~)
strict mode doesn't do that precision reduction you mentioned, resist fingerprinting is a seperate option, strict enough that firefox doesn't even show it in the settings menu. you need to go in about:config and enable privacy.resistFingerprinting
or use librewolf which enables it by default and shows it in the settings