GitLab

Now it is possible to create CAMPVis images with three dimensions but only a single slice (formerly automatically deduced as 2D image). Adapted/fixed some further code.

refs #613

* cleaned up cgt::Texture's constructors: only two left - to create an empty texture or a non-empty one
* cgt::Texture will no longer hold a copy of the image data in local memory
* removed a lot of redundant/confusing methods
* no longer needed to call uploadTexture() even though you don't want to upload sth.
* Adapted all known code to the new interface
* Removed cgt::TextureReaderDevil

refs #613

* Introducing DataSeries type (like ImageSeries but holding AbstractData, ImageSeries should be replaced some time)
* Fixed cgt::dmatX typedefs

* 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()

* Removed CameraProperty, CameraPropertyWidget and TrackballNavigationEventListener
* replaces all known occurrences of the above three with the new TrackballCameraProvider processor
* introduced TrackballCameraProvider::reinitializeCamera()

refs #141

refs #386

refs #386

refs #386

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.

* new QtJobProcessor singleton: used to execute jobs in the Qt thread
* CampvisApplication now has a map to obtain the window for a pipeline

* AbstractPipeline offers getter for the canvas to execute jobs in the pipeline's OpenGL context
* PropertyCollectionWidget adds a spacer element at the end to prevent element stretching when there is too much free space
* job.h offers new CallFunctionObjectJob to create jobs on the fly using lambda functions (the respective makeJob and makeJobOnHeap are inlined to prevent linker errors)

* Added OpenGL thread guard to image conversions to ImageRepresentationGL.

[merged commit]clean ups, fixes for g++ errors and warnings, and edits for cppcheck errors (except for the 480+ in the external library AlgLib)

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

relocated mscopysegmentation module

relocated alglib library. Compiler warning level raised to w1 to get rid of float-double conversions.

save results into csv
akima spline interpolation using alglib, deleting nearest point

alglib library. extensive trimming required

ctrl+wheel zooming, arrow movement, ctrl+z, atl+click_nearest+click to edit _nearest point

multi object, multi location, multi slide contour point/line painting

draft code for addobject deleteobject

added ContourObject class linked with add and delete button.

added a proxy class of Vec4Property/Widget as colorproperty/widget to control drawing color

Conflicts:
	modules/vis/processors/sliceextractor.cpp

edited DevilImageReader to read multiple files having same name pattern: somePrefix_[number].[extension] given the 1st file name

Worked on DevilImageReader to load single 2d image for 3d rendering

exp_01 commit

* 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

* Fixed crash (due to nullptr) in DataContainerInspectorWidget if DevIL module not present.

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.

Introducing sigslot::concurrent_pointer_list<T> a list-like container allowing thread-safe bidirectional iteration, insertion and removal of elements. Single constraint is that the element type must be a pointer type (or at least have pointer semantics) and never be 0. This is neat, as this class offers exactly what we need for a lock-free sigslot implementation.

Updated sigslot implementation to use concurrent_pointer_list for connection storage. Hence, we can get rid of the locking mechanisms, which got completely removed.

Since this simplified template definitions for sigslot, many campvis files needed to be adapted (i.e. removing the <> from has_slots<> and signal0<>).

refs #384

Conflicts:
	core/classification/genericgeometrytransferfunction.h
	core/eventhandlers/trackballnavigationeventlistener.h
	core/pipeline/processordecoratormasking.h
	core/properties/propertycollection.h
	core/properties/transferfunctionproperty.h
	core/tools/opengljobprocessor.h

Register std::vector<DataContainer*> and std::vector<AbstractPipeline*> as Qt meta types in mainwindow.cpp to support them in Qt signals (even though I do not understand why the issue did not arise before...)

* AbstractData now stores a weak_ptr to its shared_ptr owning group if existant. This avoids unintentional creation of multiple owning groups where each eventually tries to delete the AbstractData on its own (which will certainly not work)
* Updated DataContainer implementation to use a hash map instead of an unordered map.

Enforced update of min/max/singleStep values in AbstractAdjusterWidget to be performed in Qt main thread through additional indirection via Qt queued signals.

* Introduced two new tgt::LogManager log levels LuaInfo and LuaError.
* ScriptingWidget registers itself as logger and prints the Lua output into the console window.

* Implemented one single gloabel Lua VM for the entire CampVisApplication instead of one VM for each pipeline.
* The global Lua VM has a "pipelines" table/array, holding the pointers to each loaded pipeline
* ScriptingWidget support cycling through last executed commands via the arrow keys
* LuaVmState supports redirecting Lua's print() function to a custom one that uses tgt::Logmanager for printing (just as proof-of-concept). This shall later be extended to pass all Lua output to the scripting console.

With scripting enabled, the main window now has an additional scripting widget that allows to interact with a Lua VM. The current proof-of-concept implementation creates a Lua VM for every instantiated CAMPVis pipeline while the console just interacts with the first pipeline's one.
However, the Lua VM concept has to be reiterated later anyway. It may make more sense to have just a single central Lua VM for the entire application, which is shared by each pipeline.

Depending on StringProperty's display type, its property widget shows either just the QLineEdit, or additionally a browse button that pops up a QFileDialog for either loading or saving a file, or choosing a directory.

closes #43

closes #546
closes #37