Am 12.10.2015 um 17:23 schrieb Riccardo Bortolato rikyz619@gmail.com:
+HRESULT CDECL wined3d_texture_blt(struct wined3d_texture *dst_texture, unsigned int dst_idx, const RECT *dst_rect_in,
struct wined3d_texture *src_texture, unsigned int src_idx, const RECT *src_rect_in, DWORD flags,const WINEDDBLTFX *fx, enum wined3d_texture_filter_type filter)
I am not convinced that this is how we want blits to work. I was looking into some blit cleanups myself a few months ago, but got stuck in swapchain related sidequests, mostly to get rid of wined3d_swapchain_blit.
My thinking re blitting is that we want to separate things into d3d9-style StretchRect (does color conversion, multisample resolve, stretching, color keying, ...) and CopySubresourceRegion (does sysmem<->vidmem transfers). Mapping d3d8+ methods on top of these calls is pretty simple. ddraw is trickier though and I cannot promise yet that it will work. Many things can be solved with staging resources, e.g. to split a color keyed sysmem -> vidmem blit into a copy_sub_resource_region upload and StretchRect color key blit.
(StretchRect will need to be a bit more powerful than what d3d9 / d3d10 allow. At least we want sysmem<->sysmem blits supported by it).
Henri was arguing for a more powerful blitter in wined3d if I understood him right, that would also be capable of handling the upload of converted surfaces (wined3d_format_texture_info.convert in utils.c). My concern is that this kind of blitter will turn into a god object that's more powerful than what we need (e.g. we don't need signed RGB -> unsigned RGB conversion while transfering from a sysmem vertex buffer to a vidmem volume texture), but I didn't get very far in proving that my alternative approach works.