GitLab

* Debug Feature: Thread names for pipelines and some important active threads show in debugger
* fullscreen can be toggled per pipeline via the pipeline property and via ALT+Return key combination

Added a field _pipelineName to AutoEvaluationPipeline. This allows to implement AutoEvaluationPipeline::getName() so that AutoEvaluationPipeline is no longer abstract. Consequently, the LuaPipeline is no longer needed.

This change was also used to change the AbstractPipeline constructor signature to pass-by-reference instead of pass-by-pointer for the pipeline's DataContainer. This presents the semantics more clearly since the DataContainer must not be 0.

* Added default values to GenericProperty<T>
* Lua export now checks properties for default values and only sets the property if its value is different from the default value.

Renamed CampvisPainter to PipelinePainter. The PipelinePainter now directly belongs to the corresponding AbstractPipeline, which also owns the pointer and takes care of creating, (de-)initializing and destroying it.

Added virtual AbstractPipeline::paint(), which is called by CampvisPainter at the very end of rendering. This method can be used to render additional overlays directly in the pipeline.

Added onDataContainerDataAdded overload to AbstractPipeline to set pipeline dirty when the render target image has changed. Rendering of multiple canvases at the same time still broken though.

refs #641

Who would have thought that active mip-mapping during rendering creates such artifacts...

* Added new common base class RunnableWithConditionalWait that directly includes the std::condition_variable
* RunnableWithConditionalWait::stop() notifies the condition variable repeatedly as long until the thread has stopped. This avoids program hangs at shutdown due to race conditions.

Conflicts:
	core/bindings/campvis.i

* Added automatic copy of inspect.lua to binary directory to CMake build scripts
* Added AbstractPipeline::getProcessor(std::string&)

Conflicts:
	core/bindings/campvis.i

Introducing AbstractPipeline::s_init and AbstractPipeline::s_deinit signals (including Lua bindings) as first step to simplify writing entire pipelines as Lua scripts. The signals are emitted as blocking calls (via triggerSignal()) and can be used by Lua scripts to run (de)initialization code in callback functions.
This was tested with the volumerendererdemo.lua pipeline.

* Added automatic copy of inspect.lua to binary directory to CMake build scripts
* Added AbstractPipeline::getProcessor(std::string&)
* Added ScopedSynchronousGlJobExecution guard to Lua command execution to ensure having an OpenGL context present
* Fixed ordering in CampvisApplication::deinit()

signal::connect() now checks whether there exists already a connection to the same slot.

In this context, removed some redundant signal-slot connections.

refs #386

refs #386

refs #386

* Tied tgt::OpenGLJobProcessor and tgt::OpenGLGarbageCollector closer together regarding OpenGL garbage collection
* AutoEvaluationPipeline checks for valid OpenGL state after each processor call (only in debug)

* Fixed AutoEvaluationPipeline missing some updates
* Fixed AutoEvaluationPipeline::executePipeline() to execute processors too often
* Fixed ParticleFlowRenderer overwriting bound FBO
* Added Debug checks to tgt::FramebufferObject and tgt::Shader to print warnings when FBO/Shader activation would overwrite an already active FBO/Shader

Moved AbstractJob and OpenGLJobProcessor from campvis-core to tgt and adapted and cleaned up all necessary includes/references.

The new OpenGL wrapping API allows for full multi-threaded access to OpenGL contexts. Instead of one single thread scheduling all OpenGL jobs for all contexts, the new GlContextManager allows for OpenGL access from multiple threads while ensuring that each OpenGL context is acquired by only one thread at a time.

Detailed list of changes:
* tgt::GlContextManager keeping track of which threads acquire which OpenGL contexts and which threads currently have a context acquired.
* OpenGLJobProcessor does no longer schedules and execute the OpenGL calls for all existing contexts, but only for one single context that can be used for background tasks or other jobs that explicitly need a valid OpenGL context.
* AbstractPipeline now implements the Runnable interface and thus runs in it's own thread. This thread also owns the pipeline's OpenGL context.
* AbstractPipeline has a new pure virtual method executePipeline() that has to perform all computations done by the pipeline.
* AbstractPipeline now takes directly care of calling Painter::paint() of the pipeline's canvas (instead of signalling the Painter). However, the Painter interface needs further cleanup.
* AutoEvaluationPipeline was adapted to the new AbstractPipeline API, hence executing processors is no longer delegated to the OpenGLJobProcessor or the SimpleJobProcessor but entirely done in AutoEvaluationPipeline::executePipeline() and thus in the pipeline's thread.
* Adjusted CampVisApplication, DataContainerInspectorWidget, and GeometryTransferFunctionEditor to the new API.

* Fixed possible endless loop in event evaluation of AbstractPipeline.
* Fixed 4-channel image rendering in datacontainerinspector.frag.

Replaced DataContainer::s_dataAdded<const std::string&, DataHandle> with DataContainer::s_dataAdded<std::string, DataHandle>.

According to Visual Leak Detector, CAMPVis is now memory leak free. :)

* Slight changes to the API: renamed signal::trigger() to signal::triggerSignal() and signal::queue() to signal::queueSignal()
* Replaced all sigslot signal emits through operator() with emits through emitSignal() to enable debug feature.
* Fixed a possible race condition when deleting a GeometryTransferFunction and its editor window at the same time (as this will happen from different threads).

refs #384

Removed all occasions where references to DataHandles were used, since especially their use in signals may lead to segfaults or other undesired behavior.

Removed unlockInExtraThread flag from AbstractProcessor::process() - this is no longer needed as signal handling is done asynchroneously now anyway.

#ref 384

Conflicts:
	core/pipeline/abstractprocessor.cpp

Conflicts:
	core/pipeline/abstractprocessor.cpp
	core/pipeline/abstractprocessor.h

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

Refactoring AbstractProcessor::process() for clearer semantics and better and more uniform handling of invalidation levels:
 * AbstractProcessor::process() now calls updateShader(), updateProperties() and/or updateResult() with respect to the current invalidation level
 * each processor shall no longer override process() but the updateXYZ() methods, at minimum updateResult()
 * AbstractProcessor::process() takes care of (un)locking the processor itself (no need to do this from the outside anymore)

Further implicit changes:
 * Removed redundant HasPropertyCollection::updateProperties()

* Moving to Apache 2.0 license
* Updated AUTHORS.txt