On 18 May 2010 11:38, Roderick Colenbrander thunderbird2k@gmail.com wrote:
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?
Well, texture unit enables are mostly a fixed function concept, if arbfp_blit was actually shader based it wouldn't need to bother with that at all. In the general case you just invalidate the relevant states and depend on the state management to figure it out. There are some cases where that's impossible though, mostly for code that's called by state management functions itself.