GetUpdateRegion gets a window update region. The update region is reset when
BeginPaint is called, and is thereafter implicit (but unretrievable) in the
retrieved device context.
So, if I want my painting code to optimise itself by only painting objects
that intersect with the update region, I should call GetUpdateRgn just
before calling BeginPaint.
But this i'm told (and can clearly see) is no good - On a multi htreaded
system, it is possible that my paint handler will be preempted by another
app (my application has a single UI thread), that may "dirty" the screen,
adding to my update region. These changes will not be noticed by my paint
handler, and objects may not get painted.
So, then, in that case, in what situation is it _ever_ worthwile calling a
function whose data is possibly out of date the moment it returns (and is as
a result rendered essentially useless).
hmmm, my head is whispering the phrase "critical section" to me over and
over, so I'll go look in the dox to see if that/they may help in any way.
Chris.
--
Email: <pu...@qoa.yvn.arg> (ROT13 encoded to discourage spam)
Www: <http://users.lia.net/chris>
Work: <http://www.microgaming.com>
That's why you use this instead
BeginPaint()
// the former update region becomes the
// paint clip region
GetClipRgn();
>So, then, in that case, in what situation is it _ever_ worthwile calling a
>function whose data is possibly out of date the moment it returns (and is as
>a result rendered essentially useless).
You use it for advisory purposes. There are a lot of functions
whose data are possibly out of date the moment they return. For
example, "GlobalMemoryStatus()".
--
(My return address is intentionally invalid to foil spammers. Delete the
".---" to get my real address. I do this on my own time with my own money;
my responses are not to be considered official technical support or advice.)