wined3d/CopyRects bug fix

[Christopher GAUTIER]

On Tue, Sep 19, 2006, Stefan Dösinger wrote:
> Am Montag 18 September 2006 10:12 schrieb Christopher GAUTIER:
> > I've identified a bug in IWineD3DDeviceImpl_CopyRects. When CopyRects()
> > is called to copy the source entirely into the destination surface, and
> > that the sizes matches, a plain memcpy() is done. However, this assumes
> > that the surfaces have the same pitch, and this is not always the case.
> Welcome to Wine :-)

Hi Stefan,

> IWineD3DDevice::CopyRects is a subset of IWineD3DSurface::BltFast(from 
> DirectDraw), and I thought some time ago I sent a patch which makes CopyRects 
> call BltFast. This patch apparently wasn't applied, and I did a google search 
> for it and couldn't find it either. Looks like I moved it to /dev/null 
> accidentally. We should call BltFast to avoid duplicating code. BltFast is 
> also able to handle corner cases like bad rectangles.
> 
> Can you test the attached patch? I have no game which uses CopyRects, so I 
> can't test my patch. This is just a quick per-msdn implementation.

I've tested it. It works fine, and has the nice advantage of factorizing
code.

However, it has a bug that my naive patch does not have: with your
patch, the game is missing a fade from white. The main menu is supposed to be
white at the beginning, and then fade into its final colours. With your
patch, everything remains #FFFFFF-white, until the last frame of the
fading, then the menu appears normally.

I have noticed that if, in your patch, I replace the second call to
  IWineD3DSurface_BltFast(pDestinationSurface, 0, 0, pSourceSurface, NULL, DDBLTFAST_NOCOLORKEY);
by a call to IWineGDISurfaceImpl_BltFast(), then the fading is ok.

Do you have any hint of where I should look at to understand what is
causing this? I have played a bit with the GL calls, to no avail.

Apart from this point, I agree your patch is much better than mine, as
it removes code redundancy, and is probably faster :)

Cheers,
krys