2009/11/30 Stefan Dösinger stefan@codeweavers.com:
I think this will break color_fill_fbo(). My general feeling is that I'm seeing to much variants of "if (swapchain->render_to_fbo)". Also, I think this patch has parts that can be separated like e.g. the surface_init_sysmem() bit.
Out of curiosity, what would the performance impact be of always rendering to FBO?
I think this will break color_fill_fbo
I'll investigate that, but I think if it did it would break the d3d9 tests if I force rendering to the FBO - which I did for testing.
Out of curiosity, what would the performance impact be of always rendering to FBO?
I only tested it on my macs so far, because I've written this mainly to work around blitting bugs:
The performance depends on what the app is doing. I tested it with the d3d8 SDK samples, where the drawing effort is pretty small, and the present() call probably the biggest single call. Apps which do not render offscreen have a ~10% performance hit. Apps which render offscreen and need the depth blit gain about 10% performance.
That said, I think OSX always renders to a FBO behind our back, so other drivers might show different behavior.
2009/11/30 Stefan Dösinger stefandoesinger@gmx.at:
I think this will break color_fill_fbo
I'll investigate that, but I think if it did it would break the d3d9 tests if I force rendering to the FBO - which I did for testing.
I'm not sure we have a lot of tests for color fill. I actually have that somewhere on my todo list, but it's way down.
-
Henri Verbeet -
Stefan Dösinger