Re: Initial Flicker on Fade Out by Javier
Javier
Thu Feb 26 17:38:58 CST 2004
Hello,
"Stoitcho Goutsev (100) [C# MVP]" <100@100.com> escribió en el mensaje
news:%23BBpqbK$DHA.3228@TK2MSFTNGP11.phx.gbl...
>
> Javier is completely correct that the layered window has to be fully
> redrawn. But it goes only when the window (form) resizes. You can still
> invalidate some portions of the form and it will works how ot supposed to
> work.
>
> Layered window could even show better performance in some situations.
> How internaly layered windows work is all painting is redirected to
> off-screen buffer and when the painting's done alpha blending is applied
to
> the resulting picture and the result is drawn on the screen. This of
course
> is done internaly in windows and it uses the video card hardware support
for
> alpha blending if it has any.
>
I don't know the Windows.Forms implementation of this, but I've been using
layered windows for a lot of time (in W32/C++), and, while invalidating
controls does force repainting on these controls by the standard GDI API,
invalidating regions of the form does not work, and it has to be composited
again everytime anything changes (be it resizing the form, change a label's
text, press a button, or whatever which invalidates the region), it also
gets fully composited when anything under it (or any other layered window
above it) changes. Basically, anything that changes anything on the
visibility will cause it to redraw fully.
Of course, this is not a problem on any application redrawing the whole
window every frame (say any graphic demo, or some kind of realtime analizer
or visualization program), but for the kind of application that usually
waits for events to be redrawn, it's a pretty slow method taking something
is going on under the form (and that's kinda the whole purpose of
alpha-blended windows).
Hardware accelerators with decent drivers (GeForce + Detonator or Forceware
for example) do matter on this issue, as they make the painting of the
alphablended bitmap (the final window) fast, but the main compositing is
still software-rendered, and it's pretty slow when you have to redraw all
components in the window. Seems like Longhorn will get rid of all those
problems making hardware-accelerated offscreen compositing for all and every
window, including the controls in them... but that'll take some time yet :-)
> Becuse all winodw is double buffered Windows doesn't send WM_PAINT when
the
> form is moved for example or when some part of the form is uncovered. In
> such cases Windows uses double buffered image.
> When children control is moved on the form it updates as much as it is
> necessary. So the performance hit is not so big.
Uhm, maybe that's handled correctly now, but it definitely wasn't when I
tried it. It did redraw all and every control on the form (on an offscreen
buffer, yes, you don't get to see that) and it made the thing damn slow.
Invalidating rects would just do nothing when I tried... then again, I
didn't go much deeply on to it, as I basically used layered windows for
things that did redraw the whole form every frame. I might be wrong on that.
> So the easiest way to get rid if this flickering is by overriding
> OnControlCreated method and adding the following two lines:
>
> this.Opacity = 0.9;
> this.Opacity = 1;
>
> No more flickering.
>
That was a nice thing to know ;)
Javier Campos