|
ADTF
|
Besides upgrading to VS2019 on Windows Desktop (x86_64) and gcc7 on Linux Desktop (x86_64) and Linux for ARMv8 (AArch64), we updated our 3rd party dependencies. The biggest changes are Qt 5.15.2 as latest binary, code and license compatible Qt5 package, which also closes different bug reports (e.g. issues with loosed tabs and scaling issues for runtime widgets) and dev_essential with DDL Library 1.1.2 which combines the previous dependencies a_util, ddl and rpc (see also Performance during runtime). We also used this platform change to clean up, upgrade CMake to at least 3.18 and enable C++17 support (provided by the new compilers).
With the reworked OO-DDL in the DDL package coming with dev_essential, we have a massive impact and fasten performance for DDL access, usage, parsing and related operations. Please have a detailed look at ADTF Media Description SDK and DDL and ADTF 3 for further information.
With this release, ADTF officially integrates FEP as additonal open source communication especially for creating distributed systems - with or without ADTF. FEP describes a standard for interfaces and communication within distributed systems based on RTI DDS. Please have look at Distributed ADTF an linked content for the best start of the containing components, architecture decisions and first steps. For the first integration, we start with FEP Job Runner to handle FEP jobs, the grah components FEP Receiver, FEP Sender and FEP Substream Receiver for communication and two services to sync time (FEP Timing Service) and properties (FEP Property Sync Service) between ADTF and FEP. To handle FEP commands, the ADTF Control has been extended (see Available commands). Furthermore, the custom launch options from page_adtf_configuration_editor has been extended using FEP configured launch options. For your first runtime usage, please have look at the communication sessions within the the delivered example project ($(ADTF_DIR)/src/examples/projects/adtf_example_project/adtf_example_project.adtfproject).
With the usage of substreams is not only a good choice to handle high data rates and request dynamic content, you also do not have to care what a client finally needs - you just provide the content which can be requested. The next big step in this generic setup is to select, request and visualize the content and meta information on demand at runtime: the section_substream_display. With this component it is possible to create views at runtime related by the content. In the first version this is a tree view, video view and stream meta type display. In upcoming versions, DDL described content should also be plotted over time as scope view.
It is very common that an adtfplugin requires a shared library for runtime. To design this, the information has to placed within the plugindescription, which makes the dependency different for compiling, generating and runtime usage. Please have a look at CMake support for 3rd Party dependencies for usage and best practice including a workaround for CMake behaviour to prevent macro replacements. Besides this enhancements and bugfixes, we clean up the CMake support and avoid race conditions.
With the integration of the digitalwerk store, sharing, searching and downloading additional content has never been so easy. Please have a look at The Component Store Client for a first impression. This will be base to share content within your colleagues, department, company or the world, for now adtfplugin, for future also adtffileplugins, sessions, documentation and other content related to ADTF and friends. For this, we also reworked the example session and label names to give more self-explained information and getting you started and ready with ADTF.
The Property Editor handles now all information provided by the plugindescription and builds the bridge to access dependencies, provide additional meta information and open and copy content of componenents inside the adtfplugin - no matter if its part of the graph (editable) or still in Component View (read only). The views will be updated dynamically based on the content. See Property Editor for further information and a basic showcase.
Side note: If not already done, please have a look at Generate Plugin Description
There are already different options available for accessing the Trigger Pipe already:
So besides the new FEP Job Runner there is another new possibility available with this version - using RPC. For this, we deliver a RPC Runner which handles trigger via RPC (e.g. using ADTF Control)
For connecting ADTF to the world, our UDP/TCP Receiver/Sender From/To Non-ADTF Application Plugin has been extended to support UDP Multicast and provide a TCP reconnect functionality.
By default the Session Manager resolves all macros within the properties. This behaviour is conflict in some use cases, e.g. if there are several file creations during runtime using macros like or . For this, we provide an option for properties and property variables to disable the automatic resolving which can be done explicit by the component and use case itself when required. See adtf::base::property_variable::SetResolveMacros() and please have a look at Adapt macro resolving.
There are some basic extensions which are very helpful for your daily work:
Here are view keywords which has been refactored and optimized: