wined3d/CopyRects bug fix
krys at via.ecp.fr
Fri Sep 22 12:29:36 CDT 2006
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 :-)
> 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
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 :)
More information about the wine-devel