GitLab

To now, each property hat an _invalidationLevel field that was evaluated by processors when the property had changed in order to determine what has to be done. However, since properties could also be owned by other classes, this design was semantically misleading.
Therefore, it was removed with this commit and replaced by the invalidation map of each processor. Now, this per-processor mapping of property -> invalidation level is managed by the processor itself. Furthermore, the invalidation level is no longer setup during property creation but during AbstractProcessor::addProperty(), which also makes much more sense.

ATTENTION: Due to these intrusive API changes, the code of all processors and other classes handling properties needs to be changed. As a reminder, the implementation of addProperty() also now takes a reference instead of a pointer, so that old code does no longer compile.

refs #542

* Moving to Apache 2.0 license
* Updated AUTHORS.txt

Even though many float-based properties derived from
FloatingPointProperty used the same step value, T(0.01), it had to be
specified when instantiating them. To reduce boilerplate code in
property constructors, FloatingPointProperty now uses T(0.01) as the
default step value.

A new attribute has been added to all numeric properties: step value. It
determines the value of a single increment/decrement that numeric
property widgets use when their associated properties are modified using
sliders or spin boxes (users are still able to type any valid property
value in text edits).

Numerous processors and pipelines had to be updated to work with the
changed NumericProperty interface. However, choosing a well-suited step
value for each property can make it easier for users to modify the
property — using one step value for all properties leads to cases where
it is either too small, causing users to go through property values
which don't cause any visible change, or too big, making it difficult to
quickly determine the right property value.

 * DevilImageReader renders into ImageDataRenderTarget (intermediate solution...)
 * further work on IxpvDemo pipeline
 * RenderTargetCompositor knows difference compositing

git-svn-id: https://camplinux.in.tum.de/svn/campvis/trunk@389 bb408c1c-ae56-11e1-83d9-df6b3e0c105e

git-svn-id: https://camplinux.in.tum.de/svn/campvis/trunk@338 bb408c1c-ae56-11e1-83d9-df6b3e0c105e

git-svn-id: https://camplinux.in.tum.de/svn/campvis/trunk@335 bb408c1c-ae56-11e1-83d9-df6b3e0c105e

git-svn-id: https://camplinux.in.tum.de/svn/campvis/trunk@326 bb408c1c-ae56-11e1-83d9-df6b3e0c105e

Introducing Decorator pattern for processors for easy adding of generic features (properties, shader stuff):
 * Introducing AbstractProcessorDecorator and HasProcessorDecorators interfaces
 * Added ProcessorDecoratorBackground and ProcessorDecoratorMasking
 * test usage of the processor decorators in EEPGenerator (masking) and VirtualMirrorCombine (background)

git-svn-id: https://camplinux.in.tum.de/svn/campvis/trunk@292 bb408c1c-ae56-11e1-83d9-df6b3e0c105e

 * added update_legal_header.py script for updating the legal header in all code files of the project
 * ran the file => all TUMVis source files now contain the legal header

git-svn-id: https://camplinux.in.tum.de/svn/campvis/trunk@231 bb408c1c-ae56-11e1-83d9-df6b3e0c105e

 * QtContextManager uses QtThreadedCanvas
 * cleaned up tgt


git-svn-id: https://camplinux.in.tum.de/svn/campvis/trunk@198 bb408c1c-ae56-11e1-83d9-df6b3e0c105e

git-svn-id: https://camplinux.in.tum.de/svn/campvis/trunk@197 bb408c1c-ae56-11e1-83d9-df6b3e0c105e