Robert Shearman rob@codeweavers.com writes:
Changelog:
- Fix class style to include the hbrBackground member.
- Fix repainting issues introduced by this change.
- Add WM_ERASEBKGND handler and remove background drawing code from
the WM_PAINT handler.
Isn't that going to cause a lot of flicker? This was the reason for the existing code, because otherwise it looks really bad with apps that update the progress bar a lot.
On Tue, Sep 28, 2004 at 12:12:09PM -0700, Alexandre Julliard wrote:
Robert Shearman rob@codeweavers.com writes:
Changelog:
- Fix class style to include the hbrBackground member.
- Fix repainting issues introduced by this change.
- Add WM_ERASEBKGND handler and remove background drawing code from
the WM_PAINT handler.
Isn't that going to cause a lot of flicker? This was the reason for the existing code, because otherwise it looks really bad with apps that update the progress bar a lot.
Indeed, IIRC I've tried to have as optimum background drawing code as possible (in terms of overwriting areas, etc), as flicker in the progress bar would look rather ugly.
We have to be careful with these sort of changes, in that there are some controls that work real hard to avoid flicker as much as possible. Yes, the code is bigger, more complicated, and maybe sometimes not 100% the way MS does it. But if it doesn't cause any problems, having a good looking control is important IMO.
Dimitrie O. Paun wrote:
On Tue, Sep 28, 2004 at 12:12:09PM -0700, Alexandre Julliard wrote:
Robert Shearman rob@codeweavers.com writes:
Changelog:
- Fix class style to include the hbrBackground member.
- Fix repainting issues introduced by this change.
- Add WM_ERASEBKGND handler and remove background drawing code from
the WM_PAINT handler.
Isn't that going to cause a lot of flicker? This was the reason for the existing code, because otherwise it looks really bad with apps that update the progress bar a lot.
Indeed, IIRC I've tried to have as optimum background drawing code as possible (in terms of overwriting areas, etc), as flicker in the progress bar would look rather ugly.
Yes, I saw the hack we have in the Crossover code and saw the discussion last year. This code still keeps code that doesn't unnecessarily redraw the background, but the whole client area needs to be painted each time (even if normally nothing is drawn in the rest of the area), because some InstallShields depend on this for correctly displaying the % in their progress bars.
We have to be careful with these sort of changes, in that there are some controls that work real hard to avoid flicker as much as possible. Yes, the code is bigger, more complicated, and maybe sometimes not 100% the way MS does it. But if it doesn't cause any problems, having a good looking control is important IMO.
Feel free to test the code and report any flicker. I'll fix the marquee case and then send you a test program if you like.
Rob
"Alexandre Julliard" julliard@winehq.org wrote:
Isn't that going to cause a lot of flicker? This was the reason for the existing code, because otherwise it looks really bad with apps that update the progress bar a lot.
The problem with Rob's patch is that it causes entire background of the progress bar to be repainted. Some time ago (3 years or like that) I wrote tests for progress bar and found that it invalidates background only when (oldPos < newPos) and it really has a separate WM_ERASEBKGND handler. Since then my code has been removed and rewritten (by you Alexandre) for no obvious reason IMO.
"Dmitry Timoshkov" dmitry@baikal.ru writes:
The problem with Rob's patch is that it causes entire background of the progress bar to be repainted. Some time ago (3 years or like that) I wrote tests for progress bar and found that it invalidates background only when (oldPos < newPos) and it really has a separate WM_ERASEBKGND handler. Since then my code has been removed and rewritten (by you Alexandre) for no obvious reason IMO.
The reason was precisely to avoid flicker in certain cases (I believe it was during the MS Office install).
Alexandre Julliard wrote:
Robert Shearman rob@codeweavers.com writes:
Changelog:
- Fix class style to include the hbrBackground member.
- Fix repainting issues introduced by this change.
- Add WM_ERASEBKGND handler and remove background drawing code from
the WM_PAINT handler.
Isn't that going to cause a lot of flicker?
Not in the normal case. Flicker is caused when then background is drawn and then painted over by the foreground. I have kept the logic that only draws the background if the position of the progress bar has decreased. Admittedly, the invalidation in marquee mode will suffer from this problem, but I suppose that could be worked around with some careful RedrawWindow's.
This was the reason for the existing code, because otherwise it looks really bad with apps that update the progress bar a lot.
The existing code is wrong. Apps that depend on WM_ERASEBKGND doing something currently look really bad, no matter how often they update the progress bar. It would be a shame to leave have this bug remain in an otherwise completed control.
Rob
-
Alexandre Julliard -
Dimitrie O. Paun -
Dmitry Timoshkov -
Robert Shearman