"Rein Klazes" wijn@wanadoo.nl wrote:
/* Then clip again to get the source rectangle that will remain in the * clipping rect */ rcSrc = rcClip;
- OffsetRect( &rcSrc, -dx, -dy); IntersectRect( &rcSrc, &rcSrc, &rcClip);
In the first place: with this change the IntersectRect call is a no-op
I doubt you understand the reason for "to offset the source rectangle in the reverse direction":
Scrolling should only occur in the clipping rectangle. When you talk about the *destination* pixels, a clipping with the cliprect is needed. Here we are talking about the *source* pixels, from destination to source is indeed reverse. *that* is what is happening here.
Well, the committed patch 1) does fix a visual glitch in the app I'm working on and 2) passes all the current tests.
There are a couple of problems with your tests and fixes: it tests child windows with CS_PARENTDC style set, and it doesn't test the case when clipping rect is NULL. In my case both cases are not fulfilled and therefore we see different results.
P.S. I think that brackets with multiple if/else statements are mandatory to make it more clear what is going on.