WM_PAINT and GetUpdateRgn
Alex the 1'th
this region, sometimes (very rarerly) when I move another window over my
window garbage is left behind, as if the HRGN obtained is not covering all
the dirty region of my window.
Any clues as to why this is happening?
Louis Solomon [SteelBytes]
check for video driver updates
--
Louis Solomon
www.steelbytes.com
"Alex the 1'th" <AlX@a> wrote in message
news:OqMviV0o...@tk2msftngp13.phx.gbl...
Alex the 1'th
"Louis Solomon [SteelBytes]" <lo...@steelbytes.spam-is-bad.com> wrote in
message news:%23BE0OY2...@TK2MSFTNGP12.phx.gbl...
> video driver bug ?
> check for video driver updates
I don't think so, but I will try latest drivers.
Also this is happening only (as far as I can tell) with XP skinning enabled.
If it was a video bug problem it should happen allways.
Begin/End Paint which in theory does the same thing as I did, functions
flowless. This is not very helpfull as I need the acctual dirty region.
Gary Chanson
"Alex the 1'th" <AlX@a> wrote in message
>
> "Louis Solomon [SteelBytes]" <lo...@steelbytes.spam-is-bad.com> wrote in
> message news:%23BE0OY2...@TK2MSFTNGP12.phx.gbl...
> > video driver bug ?
> > check for video driver updates
>
> I don't think so, but I will try latest drivers.
> Also this is happening only (as far as I can tell) with XP skinning
enabled.
> If it was a video bug problem it should happen allways.
> Begin/End Paint which in theory does the same thing as I did, functions
> flowless. This is not very helpfull as I need the acctual dirty region.
Before you rule out video driver problems, try testing your program with
video acceleration disabled.
--
-GJC [MS Windows SDK MVP]
-Software Consultant (Embedded systems and Real Time Controls)
- http://www.mvps.org/ArcaneIncantations/consulting.htm
-gcha...@mvps.org
Norman Bullen
Are you calling BeginPaint() before calling GetUpdateRgn()? Is so,
BeginPaint() has validated the entire window area and you get an empty
region.
Are you calling BeginPaint() after calling GetUpdateRgn()? Is so,
BeginPaint() may be validating some areas that became invalid between
the call to GetUpdateRgn() and the call to BeginPaint() so you never see
them.
Are you sure that you really do paint all the areas in the region that
you get?
Norm
--
--
To reply, change domain to an adult feline.
Alex the 1'th
"Norman Bullen" <no...@BlackKittenAssociates.com.INVALID> wrote in message
news:KQA5d.3690$zG1...@newsread3.news.pas.earthlink.net...
Well, this is what I do (this is the only code, everything else is the
standard VS.NET MFC wizard generated application).
It would be nice if more people could try this and see if it is
reproductible, remember on Windows XP (fully updated) with the standard XP
skin enabled.
void CPaintTestDlg::OnPaint()
{
CBrush BrshB(RGB(0,0,255));
CDC* Dc = GetDC();
CRgn UpdateRgn;
UpdateRgn.CreateRectRgn(0,0,1,1);
int rv = GetUpdateRgn(&UpdateRgn,false);
ASSERT(rv>=2); // this never happens, GetUpdateRgn never returns any
errors
Dc->FillRgn(&UpdateRgn,&Brsh);
ValidateRgn(&UpdateRgn);
ReleaseDC(Dc);
Sigurd Stenersen
> Well, this is what I do (this is the only code, everything else is the
> standard VS.NET MFC wizard generated application).
> It would be nice if more people could try this and see if it is
> reproductible, remember on Windows XP (fully updated) with the
> standard XP skin enabled.
It seems to work without any problems on my system.
Did you try looking for an updated display driver ?
--
Sigurd
http://utvikling.com
Norman Bullen
You're allowing some time (not much, but some) to pass between getting
the update region and telling Windows to clear the update region. Any
pixels that become invalid (due to moving another window, as you
mentioned) during that time may not be included in the next update
region because you told Windows to forget about them.
Try moving the call ValidateRgn() to immediately after the call to
GetUpdateRgn().
Also, it looks like you may have a resource leak here. You are creating
regions but I don't see them being destroyed. You could create just one
region when your window is created and use it over and over and then
destroy it when the window is destroyed.
May one ask why you're doing it this way rather than the normal way with
BeginPaint() and EndPaint()?
Alex the 1'th
> You're allowing some time (not much, but some) to pass between getting
> the update region and telling Windows to clear the update region. Any
> pixels that become invalid (due to moving another window, as you
> mentioned) during that time may not be included in the next update
> region because you told Windows to forget about them.
Yes, you are correct, this was the problem.
>
> Try moving the call ValidateRgn() to immediately after the call to
> GetUpdateRgn().
>
> Also, it looks like you may have a resource leak here. You are creating
> regions but I don't see them being destroyed
CRGN destructor destoryes the acctual HRGN object.
> You could create just one
> region when your window is created and use it over and over and then
> destroy it when the window is destroyed.
Yes, this would be more efficient, but this was only a test application :)
>
> May one ask why you're doing it this way rather than the normal way with
> BeginPaint() and EndPaint()?
I'm reimplementing the whole update and redraw for windows to get
skinned/flicker-free windows/controls. For example at WM_PAINT i'm just
copying from an off-screen surface, so, I need the update region so I can
blit only the needed parts (blitting the whole offscreen surface is waaay
more inefficient then a HRGN that gets created/destroyed repetedly :) )
Thanx
ne...@rtrussell.co.uk
: I need the update region so I can
: blit only the needed parts (blitting the whole offscreen surface is waaay
: more inefficient then a HRGN that gets created/destroyed repetedly :) )
Of course, but BeginPaint gives you the update region. At least,
it gives you the update RECT (the rcPaint member of the PAINTSTRUCT
returned by BeginPaint) which is probably what you want for blitting
anyway.
Richard.
http://www.rtrussell.co.uk/
To reply by email change 'news' to my forename.
Quentin
> BeginPaint() may be validating some areas that became invalid between the
> call to GetUpdateRgn() and the call to BeginPaint() so you never see them.
<jumping into this thread as I have a similar problem>
I am seeing small intermittent invalid rects that I am not being told about
(especially when dragging another window over mine at a slow speed.)
Norm: I see what you mean about calling BeginPaint() after GetUpdateRgn()
and missing some rects that may have come in between those two calls; I
think this could be my problem. Presumably even if you call them one after
the other (as I am) there could still be missing rects? So, what is the
solution?
Quentin.
Alex the 1'th
"Quentin" <nos...@nospam.com> wrote in message
news:OcC5xeXp...@TK2MSFTNGP12.phx.gbl...
In my case to order things like this:
GetUpdateRgn
ValidateRgn
..do my own things with the rgn, paint it, etc..
If you paint the RGN then validate it, it is possible that some part of it
got invalidated again, between the paint and the vadidation, so the RGN you
though you painted is acctually invalid now, when you validate it.
>
> Quentin.
>
>
Quentin
> GetUpdateRgn
> ValidateRgn
Similiar to you, I am calling (in immediate succession):
GetUpdateRgn
BeginPaint
But I think my problem (as eluded to by Norm) is that it should still be
possible for a new invalid region to arrive between the call to GetUpdateRgn
and BeginPaint.
So how do I make sure I am handling this case?
Quentin.
Norman Bullen
a timing issue. The real problem is not just timing but the fact that
you must not validate pixels _after_ painting them if there's a chance
that they have been invalidated by some other process.
In Alex's corrected program, he is using the same region that that he
obtained from GetUpdateRgn() to validate the area of the screen that he
plans to paint. Then he paints it. If some other process invalidates
some of those pixels after he paints them, they remain invalid until he
gets another WM_PAINT message.
In your case, apperently, you are getting a invalid region from
GetUpdateRgn() and then calling BeginPaint(). If some other process is
invalidating pixels at the same time, BeginPaint() may get an update
region that is "larger" than the one you got. It will validate all of
those pixels but you're not going to paint all of them because they
weren't in the update region when you go it.
I think the answer for you is the same as for Alex: call ValidateRgn()
immediately after GetUpdateRgn() and don't call BeginPaint() or
EndPaint() at all.