On Tue, May 18, 2010 at 10:58 AM, Henri Verbeet hverbeet@gmail.com wrote:
On 18 May 2010 10:45, Roderick Colenbrander thunderbird2k@gmail.com wrote:
isn't right since set_shader does useful things as well like glEnable(tex_type).
Yeah. In the bigger picture it's also slightly insane that we have a shader based blit backend that doesn't actually use a shader for blitting most of the time, but instead invalidates lots of fixed function state.
I think we might be able to get rid of a lot of that code. At this point two out of the three cases which use the blit_shader are routed through draw_textured_quad which for instance already does the glEnable(tex_type) for us. In this case I guess if draw_textured_quad also handles glDisable (it knows the target) this could already be more efficient and get rid of unneeded state changes. The other case is swapchain_blit but as I mentioned before the non-fbo path in this call doesn't fit well into the design, so that's something I should perhaps fix first perhaps by letting it use draw_textured_quad if possible.
In general to what degree should we disable blindly disable texture_2d, cubemaps, texture_rectangle? I thought the policy (though not sure how the other code behaves) is that other code should be smart enough to enable/disable states it needs to avoid unneeded state switches or should functions clean up their own mess?
Roderick