On 29 April 2010 15:38, Roderick Colenbrander thunderbird2k@gmail.com wrote:
} else if(dstSwapchain && srcSwapchain) { FIXME("Implement hardware blit between two different swapchains\n"); It looks like this case would work fine using stretch_rect_fbo. In the end it comes down to binding two textures to an FBO and a blit which works because the different swapchains are sharing lists. Corect me if I'm wrong since I don't know the subtle details.
In principle surfaces that are on a swapchain are onscreen buffers like GL_FRONT and GL_BACK. You can make that work between different GL contexts, but it involves reading back at least one of them into a texture. The exception is when we're rendering the backbuffer offscreen, because in that case at least the backbuffers are textures as well.
} else if(dstSwapchain && dstSwapchain == srcSwapchain) { FIXME("Implement hardware blit between two surfaces on the same swapchain\n"); return WINED3DERR_INVALIDCALL; This case is for swapchain blits other than back->front. stretch_rect_fbo should be able to handle this properly except for overlaps because BlitFramebuffer doesn't support overlaps. This is no issue for StretchRect which doesn't support this either but Blt surely does (at least in some cases, so more tests are needed). Such a case could be supported by drawing in multiple passes or by just disallowing this but for that I need swapchain information in 'blit_supported'.
Well, overlaps can only happen if the source and destination surface are the same, that doesn't have much to do with being on the same swapchain. A case where you can have different surfaces on the same swapchain that aren't the front and back buffers would be a blit between different backbuffers. Multiple backbuffers is something that's currently unimplemented though.
Information about swapchains might be needed in blit_supported anyway for ffp_blit_supported. A lot of swapchain related cases (two were shown some lines up) are not supported in the ffp backend (and perhaps also in the arbfp one later on ). Some of the cases can be fixed but I fear some cases can't be. What do you think? I hope we don't have to pass variables telling that src / dst are on a swapchain and whether they are on the same.
Multiple swapchains is something that you can probably implement by switching contexts and downloading one of the surfaces into a texture in the worst case. You can probably avoid overlapped blits by checking for them in the caller and making them a separate blit operation. Worst case you can do those by downloading into a separate texture first as well, although there may be a performance consideration to make as well.