Not sure if this is a difference in the Gauge or Timer but running the
attached sample application under 2.8 and 2.9 shows that the Gauge is
updated at a much higher rate under 2.9 than 2.8. It looks like it
might be the Pulse method that is behaving differently as the timer
resolution appears to be correct when updating the gauge in
incremental mode.
Can anyone else reproduce this issue with the attached sample?
It looks like the gauge's pulse is animated so it continues to move even when Pulse is not called. Try changing your timer to 2000 ms and then compare 2.8 vs. 2.9 to really see the difference. It looks like the change on Windows is that it is now calling this when moving to indeterminate mode:
MSDN says that when zero is passed then it uses 30ms between updates, which is why it seems to move so fast. Unfortunately whoever made this change didn't provide a way to set a different animation update time, so that might make a good patch or enhancement request if you would like to be able to change it.
···
On 11/5/10 12:46 PM, Cody Precord wrote:
Hi,
Not sure if this is a difference in the Gauge or Timer but running the
attached sample application under 2.8 and 2.9 shows that the Gauge is
updated at a much higher rate under 2.9 than 2.8. It looks like it
might be the Pulse method that is behaving differently as the timer
resolution appears to be correct when updating the gauge in
incremental mode.
Can anyone else reproduce this issue with the attached sample?
Not sure if this is a difference in the Gauge or Timer but running the
attached sample application under 2.8 and 2.9 shows that the Gauge is
updated at a much higher rate under 2.9 than 2.8. It looks like it
might be the Pulse method that is behaving differently as the timer
resolution appears to be correct when updating the gauge in
incremental mode.
Can anyone else reproduce this issue with the attached sample?
It looks like the gauge's pulse is animated so it continues to move even
when Pulse is not called. Try changing your timer to 2000 ms and then
compare 2.8 vs. 2.9 to really see the difference. It looks like the change
on Windows is that it is now calling this when moving to indeterminate mode:
MSDN says that when zero is passed then it uses 30ms between updates, which
is why it seems to move so fast. Unfortunately whoever made this change
didn't provide a way to set a different animation update time, so that might
make a good patch or enhancement request if you would like to be able to
change it.
Will try to take a look into it, my time is slowly becoming more
available again.
I wonder if it was changed on other platforms to automatically animate
it as well? Because in 2.8 you need to use a timer to animate the
pulse behavior.
It is kind of nice if you can just call pulse and let it handle it
internally instead of needing the timer.
Thanks,
Cody
···
On Fri, Nov 5, 2010 at 3:04 PM, Robin Dunn <robin@alldunn.com> wrote:
It's always been animated on the Mac. I'm not sure about wxGTK
···
On 11/5/10 1:12 PM, Cody Precord wrote:
Hi,
On Fri, Nov 5, 2010 at 3:04 PM, Robin Dunn<robin@alldunn.com> wrote:
On 11/5/10 12:46 PM, Cody Precord wrote:
Hi,
Not sure if this is a difference in the Gauge or Timer but running the
attached sample application under 2.8 and 2.9 shows that the Gauge is
updated at a much higher rate under 2.9 than 2.8. It looks like it
might be the Pulse method that is behaving differently as the timer
resolution appears to be correct when updating the gauge in
incremental mode.
Can anyone else reproduce this issue with the attached sample?
It looks like the gauge's pulse is animated so it continues to move even
when Pulse is not called. Try changing your timer to 2000 ms and then
compare 2.8 vs. 2.9 to really see the difference. It looks like the change
on Windows is that it is now calling this when moving to indeterminate mode:
MSDN says that when zero is passed then it uses 30ms between updates, which
is why it seems to move so fast. Unfortunately whoever made this change
didn't provide a way to set a different animation update time, so that might
make a good patch or enhancement request if you would like to be able to
change it.
Will try to take a look into it, my time is slowly becoming more
available again.
I wonder if it was changed on other platforms to automatically animate
it as well? Because in 2.8 you need to use a timer to animate the
pulse behavior.
It is kind of nice if you can just call pulse and let it handle it
internally instead of needing the timer.