1/2 wined3d: Implement IWineD3DDeviceImpl_ColorFill using ClearSurface instead of 'BltOverride'

[Roderick Colenbrander]

On Fri, Mar 12, 2010 at 11:58 AM, Stefan Dösinger
<stefandoesinger at 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