Use C++11 override everywhere it is appropriate.
Rework uniform setting. One would think something as mundane as setting a few uniforms wouldn't really mean much for performance, but seemingly this is not always so -- I had a real-world shader that counted no less than 55 uniforms. Of course, not all of these were actually used, but we still have to go through looking up the name etc. for every single one, every single frame. Thus, we introduce a new way of dealing with uniforms: Register them before finalization time, and then EffectChain can store their numbers once and for all, instead of this repeated lookup. The system is also set up such that we can go to uniform buffer objects (UBOs) in the very near future. It's a bit unfortunate that uniform declaration now is removed from the .frag files, where it sat very nicely, but the alternative would be to try to parse GLSL, which I'm a bit wary at right now. All effects are converted, leaving the set_uniform_* functions without any users, but they are kept around for now in case external effects want them. This seems to bring 1–2% speedup for my use case; hopefully UBOs will bring a tiny bit more.
Collapse passes more aggressively in the face of size changes. The motivating chain for this change was a case where we had a SinglePassResampleEffect (the second half of a ResampleEffect) feeding into a PaddingEffect, feeding into an OverlayEffect. Currently, since the two former change output size, we'd bounce to a temporary texture twice (output size changes would always cause bounces). However, this is needlessly conservative. The reason for bouncing when changing output size is really if you want to get rid of data by downscaling and then later upsampling, e.g. for a blur. (It could also be useful for cropping, but we don't really use that right now; PaddingEffect, which does crop, explicitly checks the borders anyway to set the border color manually.) But in this case, we are not downscaling at all, so we could just drop the bounce, saving tons of texture bandwidth. Thus, we add yet more parameters that effects can specify; first, that an effect uses _one-to-one_ sampling; that is, that it will only use its input as-is without sampling between texels or outside the border (so the different interpolation and border behavior will be irrelevant). (Actually, almost all of our effects fall into this category.) Second, a flag saying that even if an effect changes size, it doesn't use virtual sizes (otherwise even a one-to-one effect would de-facto be sampling between texels). If these flags are set on the input and the output respectively, we can avoid the bounce, at least unless there's an effect that's _not_ one-to-one further up the chain. For my motivating case, this folded eight phases into four, changing ~16.0 ms into ~10.6 ms rendering time. Seemingly memory bandwidth is a really precious resource on my laptop's GPU.
Merge branch 'epoxy' Conflicts: effect_chain.cpp resource_pool.cpp
Cache the FFT support texture. Regenerating it every time is a waste of CPU, and also of GL state changes.
Merge branch 'master' into epoxy
Formalize the notion of messing with sampler state. This kills a lot of the assumptions that have been going around, and should allow us to deal much better with the situation when we have two or more inputs to an effect (where you basically can't predict the sampler number used reliably); there's still an edge case that's documented with a TODO, but this is generally much better.
Switch from using GLEW to epoxy. The main reason is that we would like to support GL 3.2+ core contexts, and then later quite possibly GLES.
Move everything into “namespace movit”. This is a pretty hard API break, but it's probably the last big API break before 1.0, and some of the names (e.g. Effect, Input ResourcePool) are really so generic that they should not be allowed to pollute the global namespace.
Another round of include-what-you-use.
Add a new effect that can do FFT/IFFT.