Better fix for [bug 829] (same surface display corruption)

[Lionel Ulmer]

> I took Lionel's sugestions to heart and came up with a better fix for 
> bug 829. This has a better check for defining when the corruption could 
> occur and should be a little faster

Well, I had not in mind exactly what you did.

> +        SameSurfaceOK = (!((src == iface)&&(sbase < dbuf)&&(xdst.top < xsrc.bottom)&&(xdst.left < xsrc.right)));

I do not really understand all the details of this check, so a comment would
be nice, but well, I think it is unneeded (see below).

> +                    if (SameSurfaceOK) {
> +                       for (y = 0; y < dstheight; y++) {
> +                          memcpy(dbuf, sbuf, width);
> +                          sbuf += sdesc.u1.lPitch;
> +                          dbuf += ddesc.u1.lPitch;
> +                       }
> +                    } else {
> +                       
> +                       sbuf += (sdesc.u1.lPitch*dstheight);
> +                       dbuf += (ddesc.u1.lPitch*dstheight);
> +
> +                       for (y = 0; y < dstheight; y++) {
> +                          sbuf -= sdesc.u1.lPitch;
> +                          dbuf -= ddesc.u1.lPitch;
> +                          memcpy(dbuf, sbuf, width);
> +                       }
> +                    }
> +

The problem I can see is that you use 'memcpy' even in the SameSurfaceNotOK
case. And this is bad as memcpy does NOT handle overlapping memory zones.
Moreover, you only have the 'descending' copy order in that case and not
both cases.

What I had in mind in my comments to your patch was something like that :

 if (src != iface)
    Do the standard memcpy code path
 else
    if source_Y > dest_Y
      do the ascending memmove copy
    else
      do the descending memmove copy

This way you did not hurt the common case (ie Blt from two different
surfaces). Now I agree that even in the same surface case, one could add
some checks to see if the rectangles overlap or not, but I do not know if it
would be worth the pain as memmove should not be THAT slower than memcpy.

                     Lionel

-- 
		 Lionel Ulmer - http://www.bbrox.org/