[PATCH 5/7] wined3d: introduce a new wined3d_texture_blt function

[Stefan Dösinger]

> Am 12.10.2015 um 17:23 schrieb Riccardo Bortolato <rikyz619 at 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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20151013/ee59a541/attachment-0001.sig>