On Sunday, March 27, 2011 1:57:17 AM Stefan Dösinger wrote:
BltOverride is a horrible mess, and I'm afraid the patch doesn't make it any better. A long time ago Roderick started a cleanup to give the blit selection routine a more structured approach, but he never finished the work. Unfortunately a proper fix is not a weekend task :-(
Ultimately, I think the best approach would be to properly split up the blitters. Currently, WineD3D uses a catch-all Blt method that handles almost all blitting possibilities (including color-keying), with a fallback to do manual conversions and blits if an "accelerated" path is missed or not available, and also handling color-fill (and patterned drawing?).
The way D3D9 does it, there's different methods to handle blitting to and from various types of surfaces (eg, StretchRect for vidmem->vidmem only, no color- keying, and acts as a resolver for multisampled surfaces). If I could, I'd add methods to IWineD3DDevice to handle it that way. Different methods for different purposes, and making the d3d/ddraw dlls select the appropriate blitter. Although it'd result in a bit of duplication until the monolithic Blt method can be removed, and I'm not all too familiar with wined3d's resource handling, nor do I know how to properly add new methods to wined3d interfaces.
Given how daunting a proper cleanup is, I figured it'd still be a good idea to handle more cases for accelerated blits with a "simple" patch, instead of letting it go vidmem->sysmem[->conversion->sysmem]->stretch->sysmem->vidmem, in addition to necessitating more converters that aren't otherwise needed (without this patch, it needs to use argb8->xrgb8 and rgba16f->xrgb8 converters, the latter of which doesn't exist and adding it would be just as much of a hack as playing with BltOverride, IMO, not to mention being left with really crappy performance).