EDIT: updated the attached code. Code generation and HalfPixelShift are now done.
EDIT2: fixed bug in code enabling HalfPixelShift and some erroneous comments. Attachment updated.
EDIT3: fixed some comments and asserts.
EDIT4: update task mechanism added; it is now a registrable for each individual Filter. ScanlinesFilter provides an example.
EDIT5: the attachment in this post is the last version before the module split; it is now obsolete. See the later post, including code that has been split into modules.
A first version of the CommonFilters re-architecture is almost complete.
I still need to split the code into modules and add imports, and port most of the existing filters (including my new inker) over to the new architecture, but the infrastructure should now be in place.
I expect to get to the testing phase in a day or two.
Some highlights:
- Multi-passing with automatic render pass generation based on filter properties. Filters are assigned to logical stages (corresponding to steps in the simulated image-forming process), and the pipeline figures out dynamically how many render passes to create and which stages to assign to each. This allows e.g. blur to see cartoon outlines, opening up new possibilities.
- Allows mixing filters provided with Panda and custom filters in the same pipeline, as long as the custom filters are coded to the new Filter API (which is the same API the internal filters use). The API aims to be as simple as possible. This also makes it easier to contribute new filters to Panda.
- Filters may define internal render passes, allowing filters with internal multi-pass processing. (This is just to say that the new architecture keeps this feature!)
- Highly automated. Create run-time and compile-time filter properties with one-liners (or nearly; most of the length comes from the docstring). Assign a value to a filter property at run-time, and the necessary magic happens for the new value to take effect, whether the property represents a shader input or something affecting code generation.
- Runtime-inspectable; filters have methods to extract parameter names, or parameter names and their docstrings. You can also get the current generated shader source code from each FilterStage by just reading a property.
- Object-oriented architecture using new-style Python objects. Using inheritance it is possible to create specialized versions of filters (to some degree).
- Exception-based error handling with descriptive error messages to ease debugging.
Comments would be appreciated 
filterinterface.zip (48.7 KB)