-
Welcome to B4X forum!
B4X is a set of simple and powerful cross platform RAD tools:
- B4A (free) - Android development
- B4J (free) - Desktop and Server development
- B4i - iOS development
- B4R (free) - Arduino, ESP8266 and ESP32 development
Timer in microseconds
- Thread starter Toley
- Start date
- Similar Threads Similar Threads
No. Setting the timer to an interval of 1 ms results in a real timer interval of ~15ms on my devices.
Upvote
0
More than 20ms on mine. And even with much higher values, their interval is irregular. That's why I definitely don't use them and prefer to use a loop where I measure the elapsed time.
Upvote
0
That's completely wrong and absolutely right at the same time. It depends strongly on the OS used. Let's me prove it with the attached application (simple to use: you click on a button and wait 10 seconds). With ICS or JellyBean, you'll get no deviation (or very small, usually on the first tick) with the "busy loop" method, and a small but always there deviation with the timer. On an older device under Gingerbread, the timer is more regular.
EDIT: to give an idea, here are the results on a device under JellyBean (single core 1 Ghz):
After 2 minutes, the timer has accumulated a deviation of 802 ms. The "busy loop" only 10ms. Moreover, the busy loop is never ahead of the time, contrary to the timer.
Last edited:
Upvote
0
In 2 minutes, the total deviation for the timer was only 0.6%. For the "busy loop" 0.008 %. Apart from intensive games, I dont think you really need microsecond accuracy.
Anyway, my reason for not using "busy loops" is that it breaks android time-sharing framework.
- Does not allow events or interrupts to be raised. This includes system events like even orientation changes.
- Keeps the processor alive doing no work. Inefficient programming.
Upvote
0
I don't think that Erel meant "better" as in more precise but "better" as in consuming less processor resource and hence increasing battery life. Also DoEvents, unlike returning to the main message loop does not process all types of message in the message queue.
Upvote
0
I agree with both of you on the fact that a timer is sufficient in most cases and is more suited to B4A, but I noticed that it was better to choose another solution in two cases: for a short and quick animation (my first tries with a timer were not satisfying for my SlidingSidebar class for example) and when the regularity is critical (e.g. for a metronome). As the timer is sometimes ahead of time, sometimes behind, it's really too irregular for an audio application. A lag above 20ms is noticeable by any experienced musician (as I am) and disturbing when you play a fast song. The audio applications for PC or Mac offer a latency (hardware+software) below 10ms and almost no deviation during a whole session. It's what is expected from a mobile application too (or the application is just a toy).
If you look at the code of a game engine, you'll see that it doesn't trust at all the regularity of the timer (when they use one, some rely only on a main loop). Sprites and other animated objects have usually a speed in pixels per second and their position is computed with the elapsed time from the previous frame. You don't see code like : sp.x = sp.x + 2, which supposes a very good regularity of the timer, but things like: sp.x = sp.x + 50 * deltaTime. If you wonder why x and y are float values in the Android API, now you know.
About the CPU consumption, it is obvious that my example, doing nothing, is a complete waste of CPU time. But in a real app, this loop is used to call code and most of the CPU time is consumed by this code, not by the loop. We have to keep in mind that the purpose of this loop is also to indicate precisely when we are compared to the beginning or the previous tick, so to estimate the progress of an animation for example. A timer does not provide this information (fortunately, since Honeycomb, we have TimeAnimator in Java; we can even set a FrameDelay to force it to respect the given pace).
If you look at the code of a game engine, you'll see that it doesn't trust at all the regularity of the timer (when they use one, some rely only on a main loop). Sprites and other animated objects have usually a speed in pixels per second and their position is computed with the elapsed time from the previous frame. You don't see code like : sp.x = sp.x + 2, which supposes a very good regularity of the timer, but things like: sp.x = sp.x + 50 * deltaTime. If you wonder why x and y are float values in the Android API, now you know.
About the CPU consumption, it is obvious that my example, doing nothing, is a complete waste of CPU time. But in a real app, this loop is used to call code and most of the CPU time is consumed by this code, not by the loop. We have to keep in mind that the purpose of this loop is also to indicate precisely when we are compared to the beginning or the previous tick, so to estimate the progress of an animation for example. A timer does not provide this information (fortunately, since Honeycomb, we have TimeAnimator in Java; we can even set a FrameDelay to force it to respect the given pace).
Upvote
0
Interesting that you did mention these three scenarios. I am going to post a class that uses a timer for animation (I couldnt find the suitable animation), I wonder what issues that might bring. I agree with time sensitive things like a metronome or a high performance game engine, that would require a lot of hard work.
Upvote
0
Hi guys,
I liked this threads!
I tried the Timer example posted by Informatix, I need to use the LOOP button sub but if I add an ACTIVITY_TOUCH sub, this is never called during a DOEVENTS loop.
Why? Is it possible to test during the loop if user touched the screen and getting the x,y coordinates?
Thanks
I liked this threads!
I tried the Timer example posted by Informatix, I need to use the LOOP button sub but if I add an ACTIVITY_TOUCH sub, this is never called during a DOEVENTS loop.
Why? Is it possible to test during the loop if user touched the screen and getting the x,y coordinates?
Thanks
Upvote
0
You have to set a touch listener with the Reflection library and use only the touch events raised by this listener.
Upvote
0