On Fri, Mar 12, 2010 at 11:58 AM, Stefan Dösinger stefandoesinger@gmx.at wrote:
Am 11.03.2010 um 22:34 schrieb Roderick Colenbrander:
Hi,
This patch makes IWineD3DDeviceImpl_ColorFill use Clear instead of BltOverride for color filling (it falls back to software blit if this is not possible). This change makes it possible in a next patch to have the GL Blt call IWineD3DDevice_ColorFill instead of the way around.
Regards, Roderick Colenbrander <0006-Implement-IWineD3DDeviceImpl_ColorFill-using-ClearSu.patch>
I am still wary of the changes to Blit because I have not seen(or have not understood) the overall design goal of how blits should work, and especially how ddraw blits and d3d8/9 style blits work together. This is especially visible in your patch because you still call IWineD3DBaseSurfaceImpl_Blt from ColorFill, you just moved the software vs gl codepath decision to a different place. It may be a step in the right direction, but I'd still prefer to see the overall strategy first.
The final goal is to make the surface code more efficient and to clean it up (e.g. finally fix that p8 mess). The first area I worked on is BltOverride which is now shared between ddraw/d3d8/d3d9. What I'm doing is to get rid of ddraw-specific things like color keying, color filling and palette stuff. I have moved this code to dedicated helper functions which I'm calling from Blt/BltFast. In the end I hope to call BltOverride from Blt/BltFast only for 'StretchRect'-like functionality. The real StretchRect also should not be routed through Blt in the end. (Move most software Blt code to a software StretchRect and call that from base Blt)
Regarding ColorFill falling back to IWineD3DBaseSurfaceImpl_Blt. Most likely the base version of Blt should be split in a ColorFill function (there is already one but it is private to surface_base.c). Something similar could be done for a software StretchRect fall back but I think it would cause code duplication and perhaps we can hope that FBOs are around or do it all using OpenGL there since StretchRect requires D3DPOOL_DEFAULT.
I hope this answers your question enough.
Roderick