Hi, I am trying to writing a progress bar animation for 1 second from zero to 100%; it is very simple as follows:
The progress bar is a canvas aligned in left side of window (left:0)
The window width is 1000
I have a timer that adds +1 to canvas width every millisecond
The problem is that in reality this is way slower than I was expecting because I can clearly understand it takes much more than one second (or 1000 milliseconds) for the canvas to reach a width of 1000 pixels.
Probably the cause is my system+graphics resources/delay (this is a corei7 laptop) so I presume the behavior would be different on different machines with different specs even though I can simulate a 1 sec animation for my machine.
This is hardly going to be possible as what you ask is literaly a 1000 frames per second. A more reasonable fps would be 60 fps so set your timer to 16 ms and add +60 every tick, but even then it’s not a guarantee on every machine.
Only good way is using a delta = (endTime - startTime) and depending on this delta calculate the position on the progressbar so that when 1 second has passed you’ve reached the end: (delta * x) = 1000 when delta = 1. Lookup sprite animations in google to see the concept.
[quote=130756:@Walter Sander]I have a timer that adds +1 to canvas width every millisecond
The problem is that in reality this is way slower than I was expecting because I can clearly understand it takes much more than one second (or 1000 milliseconds) for the canvas to reach a width of 1000 pixels.
Probably the cause is my system+graphics resources/delay (this is a corei7 laptop) so I presume the behavior would be different on different machines with different specs even though I can simulate a 1 sec animation for my machine.
Has anyone here went through a similar issue?[/quote]
Instead of milliseconds, use Ticks, which is a 60th a second. If it still chokes, do the update every two ticks.
@Michel Bujardet sorry the off-topic, your solution looks good and I have never used Ticks before; but…what happen with Ticks INT value once it reaches the maximum 32-Bit / 64-Bit INT limit ?
In a 12 month period, I’d expect any computer to have an OS or Security update which would require a system reboot. If not, these days the system would be vulnerable to a series of exploits.
If you really fear the very remote possibility that your one second ProgressBar trip takes place dead in the middle of the precise second when the rollover occurs, move your width with a variable that increments every time Ticks value gets different, no matter what it is.
Somehow, I am not sure I would fear the possibility, but since it exists, here you go
@Michel Bujardet to calculate the length (in pixels) of the progress bar in a specific moment, I need to subtract current Ticks number from the Ticks number of the previous progress bar update which is stored in a global var (property)
This means, I expect the current Tick number to be always bigger than the previous one
or …
I need to know what the biggest possible INT number for the current machine is, in order to prepare the animation for any eventual “roll over’s”
[quote=130950:@Walter Sander]@Michel Bujardet to calculate the length (in pixels) of the progress bar in a specific moment, I need to subtract current Ticks number from the Ticks number of the previous progress bar update which is stored in a global var (property)
This means, I expect the current Tick number to be always bigger than the previous one
or …
I need to know what the biggest possible INT number for the current machine is, in order to prepare the animation for any eventual “roll over’s”[/quote]
Statistically, it is highly improbable that your progressbar will happen to be moving exactly at the second the rollover will occur, in a year or so.
Well, if you are still afraid to be at the fated edge of the rollover, jus test the value of Ticks against 2,147,483,647 which according to the LR is the maximum an UINT32 can hold. If you still have 60 to go, then you got your second of travel and can go ahead. If you have less than 60, then simply wait until the rollover takes place and start moving at zero.
If against fate you insist on the progressbar to move during the rollover, use a timer set with a period of 17.
