WCX unpack progress bar performance on Vista

[tbeu]

HolgerK and I observed significant performance differences of the unpack progress bar between Vista and XP. In ProcessFile() of my packer plugin the function ProcessDataProc() is called for every single change, i,.e. every 8 Byte.

Our test case was a 16MiByte large data file, hence ProcessDataProc() was called 2000000 times. The progress bar style was the native OS style, i.e. NewStyleProgress=1. It took 8 seconds to unpack the test file from the arcive on WinXP and 555 seconds for the same operation on Vista. So Vista unpacked and displayed the progress bar about 70 times slower than XP.

As a workaround, with NewStyleProgress=0 in the wincmd.ini of Vista it will unpack as fast as on XP.

Finally, my suggestions are:

1) TC should not update the progess bar whenever ProcessDataProc() gets called. Instead, the progress bar should only be updated every 1% increase or so.
2) If TC will not change the progress bar update behaviour every packer plugin author needs to consider the update behaviour himself and must call ProcessDataProc() less often.

Best regards
Thomas

[ghisler(Author)]

Good points, I will put that on my to do list. However, calling ProcessFile() every 8 bytes is a bit too much, isn't it?

[CoolWater]

A bit offtopic but an interessting thing for me... What I observed using a program under Vista is, that MS changed the behavior of the progressbar. Means, setting PBM_SETPOS to the maximum defined value does not guarantee the progressbar to reach the end, i.e. the green bar does not reach the right side although (internally) the progressbar was set to 100%. What I observed is, the longer the operation takes the better is the chance to see the progressbar @ 100%. So I guess MS added a "time factor" which has more priority than the actual value set.

This there a workaround to ensure that the progressbar will always reach the end?

TIA,
CoolWater

[HolgerK]

2CoolWater

Funny, I'd never noticed this.

It seems that the vista progress bar animates the movement between two positions. And this animation takes about 1 second

One workaround:
1. set position to 100
2. move position backward to 99
3. set position again to 100

The animation is only active if you move the progress forward, not while moving progress back.
As a result the animation is only active for the last step from 99 to 100.
Doing the same with a maximum range of 1000 the animation isn't noticeable.

Kind regards,
Holger

[ghisler(Author)]

Nice hack!

I will consider adding that to TC, the current Vista implementation is really sub-optimal...

[CoolWater]

2HolgerK

Thanks for this info But this doesn't work for me. When I said the PB does not reach 100%, it might reach 99% but in most cases it reaches (visibly) only 20-30-40%. In VC6 I use PBM_SETRANGE to set the range. Min is 0, max is 100. Would it make a difference if I'd use PBM_SETRANGE32?

My java programs show the same effect using SWT (Standard Widget toolkit, a framework which uses the native OS controls and accordingly the L&F of the native OS).

Btw, TC shows a similar behavior on Vista here... When copying a file of about 20 MB, the percent label shows 100% but the progressbar shows about 60 %...

Regards,
CoolWater

[ghisler(Author)]

2CoolWater
Have you tried the suggested workaround (not part of TC yet)?
1. Set range to 0..1000
2. Set position to 1000
3. Set position to 999

The trick seems to be to let the bar move backwards...

[CoolWater]

Ok, seems to work perfectly

Thanks for the hint HolgerK and ghisler

Regards,
CoolWater

[HolgerK]

2CoolWater

One additional note:

In progress dialogs the last WM_PAINT can be overtaken by the WM_CLOSE message, if the dialogs will close directly after the 100% progress event is reached.
In this case the progress bar isn't updated with the last progress.
You can prevent this, using a single shot timer with an interval about 200ms, and moving the close dialog handling into the OnTimer handler.

Kind regards,
Holger

[CoolWater]

2CoolWater

One additional note:

In progress dialogs the last WM_PAINT can be overtaken by the WM_CLOSE message, if the dialogs will close directly after the 100% progress event is reached.
In this case the progress bar isn't updated with the last progress.
You can prevent this, using a single shot timer with an interval about 200ms, and moving the close dialog handling into the OnTimer handler.

Kind regards,
Holger

That's right but was not the case

Regards,
CoolWater

[HolgerK]

1) TC should not update the progess bar whenever ProcessDataProc() gets called. Instead, the progress bar should only be updated every 1% increase or so.

01.04.08 Fixed: Improved progress bar performance for plugins by updating the bar only when the percentage changes (this has been done for internal functions for a long time)

This is fixed for the single progress bar (now approximately as fast as NewStyleProgress=0), but still very slow if two progress bars (unpack of multiple files) are shown.

Kind regards,
Holger

[ghisler(Author)]

Strange, the second progress bar already remembered the position before TC 7.03!