"Rein Klazes" <[EMAIL PROTECTED]> 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.
--
Dmitry.
