Skip to content

Component Status

Bjorn Stahl edited this page Mar 2, 2019 · 6 revisions

This page gives an overview of project parts and estimated completion status (in regards to the distant 1.0 release) along with notes on what is assumed to be missing or lacking.

For more detailed planning, see the full Roadmap.

Engine Components

Graphics Layer

Feature- wise little new needs to be added, it is primarily missing cleanup, documentation and performance optimizations, otherwise mostly bugfixes until 0.8/0.9.

3D Graphics

Primarily intended for simpler forms of model viewing and the basic set of effects (no advanced scenes / physics by default though possible plug-in option), at the least, it still lacks proper culling, VBO support, a fast path for mapping device input to camera orientation, animation subsystem and graph visualization.

Audio

Still very primitive and old code- base. Should be refactored into a platform layer to allow for non-openAL, simplified version (ties in with LWA). Lacks audio effect matching, multichannel output configuration, basic synthesis, listener device management and control, HRTF (in regards to 3D). Planned to change in the 0.6-0.7 phase.

Special Devices

Special devices covers LED controllers, advanced input device such as eye trackers, MEMS sensors and a number of assistive devices. Currently, the ones usable for VR applications are being added to a separate tool / subsystem.

Lua Interface

This component grows organically with the other features, but integration with IDEs and Debugging need more work still. The event propagation is rather 'string heavy' and a fastpath with numeric IDs should be provided for the noisiest ones (input and frameserver callback).

WM and Drawing Protocol

This builds on the API defined by the Lua interface, reusing its documentation as an IDL and a recompilation of the lua translation unit to act as a protocol in order to allow external window managers in the traditional 'X' style of things.

Database

Feature-complete outside possible advanced niche features like splitting/ merging subtables, Quality Assurance activities remaining.

Input / Event Model

Support scripts for touchpad support (present in durden at the moment) still lack some quality and diversity work. The edge cases where connected clients stall and their incoming event queue is filled up is still poorly (i.e. overwrite) handled. The plan is to add better error handling in associated lua calls and a local feedback event (though asynch) in an ANR (application-not-responding) fashion. Also need support scripts for converting keymaps from various local platform specific formats e.g. Android.

LWA

Related to progress in the rest of the engine, but also lacks a simplified audio fastpath (little- to no mixing, output straight to shmif) to reduce dependencies further, and for more clever mapping of shmif features in regards to state- transfer, clipboard etc.

SHMIF

Most corner cases have been hammered out, mostly lack additional test vectors, especially for malicious use, along with the advanced extensions in terms of GPU migration and special data format support e.g. vector and text- buffer interpretation.

TUI

Better multi-window handling with overlay support and integration with shmif-server to nest/embed graphical subtasks.

Frameservers

Decode

Libvlc is overly complex/modular distribution wise, and the frameserver severely lacks of AV quality work and advanced feature mapping (overlay subsegments for subtitles etc). All image parsing, 3d models, font parsing etc. should move into decode.

Encode

Add support for more advanced encodes, e.g. text to speech and speech recognition. QA and optimization work, simplified version that does not rely on all of ffmpeg to work but rather whatever the best/least-patent-plagued A/V/Mux combination is out there currently.

Remoting

QA and more advanced VNC features, integration with the A12 state machine, primarily internationalization, QEMU raw keyboard extension and clipboard features. Alternative/more rich implementation that supports RDP and SPICE.

Gaming

Mostly QA and synchronization with changes in libretro.

Net

Primitive implementation still - will be swapped out and replaced with the a12 state machine from the netproxy tool, along with a local message queue discovery system like zeroMQ.

Terminal

Quality work in terms of bugs with legacy edge cases and support for more common/uncommon escape sequences. Possibly also a simpler (st-) derived state machine backend would help as the current one is a bit too complex. A special 'LASH' mode that switches to a model that replaces the normal CLI shell with TUI integration is also left.

Sandboxing

Multiple experiments exist out-of-source, with the aloadimage tool acting as a testing ground. No actual progress until 0.6/0.8.

Interposition Libraries

The present ones are still more experiment than serious feature, SDL-1.2 one is reasonably complete though need more testing / exposure. a libpulse target is high up on the list, though will likely be added as a 'full' driver for pa via the waybridge instead.

OS Specific Ports/Platforms

There are more ports and platforms for even more toxic ecosystems such as Android and iOS, but those are not publicly available and treated more like experiments than supported efforts. The current ones should map better to system features, see experiments/side-projects.

Linux

The Linux platform is the most complete in that more advanced accelerated graphics- and handle-passing features are supported, along with lower level display and input integration. This primarily needs more testing and tuning on a wider assortment of hardware, and for the related drivers to evolve. The side case of supporting multiple active GPU combinations and (PRIME) dynamic switching between the two still needs work, along with suspend/resume style launch_external implementation.

BSDs

The FreeBSD platform has developed somewhat slower due to lack of access to hardware with driver support for accelerated buffer sharing, and same goes for OpenBSD.

OS X

The OSX platform does not have tight hardware integration e.g. multiple displays, DPMS or native graphics interface as it relies on SDL1.2 for graphics and input management. The SDL1.2 implementation does not yet expose display mapping interface, dynamic resizing or retina. Some of this can be improved by switching to SDL2.0. It also lacks generic display server properties e.g. accelerated buffer sharing. The bigger problem by now is however the lack of shared memory resizing (no multiple ftruncate on posix shared memory because their implementation is shit) forcing us to overcommit which really hurts in use-cases e.g. durden where titlebars etc. may result in large allocations. It is also the show-stopper for getting rid of named semaphores in favor of having them be inherited/living as part of the shmpage.

Windows

The Windows platform has been deprecates since 0.4 due to lack of time/resources and interst. If it gets re--enabled, depends on how well windows progress with the integration of LLVM/Clang, its linux-compatibility layer, Posix compatibility and possible the MIDIPIX library, as maintaining a separate shmif- backend is not currently worth the effort.

Graphics

The major missing component for current graphics techniques as used with the AGP platform is the support of a software based renderer and a quality OpenGL 4.x path that uses the more advanced synchronization, compute and transfer paths. The GLES platform is slated for deprecation as the open source driver for Raspberry Pi etc. improve.

Support Systems

Documentation

Documentation needs a lot of proof reading and correction from native English speakers (with a technical focus of course) and the ruby scraping scripts that generate man pages need some improvements in the generated formatting. While coverage is complete or near-complete, a lot of it reads more like mental notes than serious text.

Test Suite

The test suite is still rather fragmented with a lot of partially completed automation. Integration with other notification systems (irc bots, progress pages) is still missing entirely.

Build System

Although the build system grows organically with other development in the project, the big missing points are that some cmake modules are rather immature and user-unfriendly and that there is no distribution specific packaging and deployment.

Tools and Backends

Xarcan

Basic operations with glamor, dri3 etc. working, though advanced use like GLX easily runs into driver issues or switches to software- fallback implementations. Gamma controls/XRandr mapping does not support multiple- displays. Clipboard integration can be done with the separate Aclip tool.

Qemu

Missing native cursor integration, state management, Virgil support implemented but not working / unstable. A lot more experimental things to do here outside the normal progression.

Wayland

See the src/tools/waybridge/README for detailed status. The bigger blocks to development right now is the overall quality of toolkits with wayland backend support and the immaturity of the ecosystem when it comes to basic engineering in terms of verifying compliance and so on.

Vrbridge

Basic idea and interface in place, but infinite room for expansion. Treading somewhat carefully since Khronos seem to have its sights set for standardization in this area.

Aclip

Basic text management in place. Missing more advanced features like audio, video and binary blob management.

Aloadimage

Basic idea, playlist, controls, sandboxing and so-on in place. What's missing is advanced color space controls, optional accelerated buffer transfers and native support for future HDR formats.

Arcan-net

Event and video transports in place, basic compression as well. Basic crypto missing as well as subsegment negotiation. Better queueing, transport and adaptive compression needed.