-
Notifications
You must be signed in to change notification settings - Fork 89
Component Status
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.
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.
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.
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 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.
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).
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.
Feature-complete outside possible advanced niche features like splitting/ merging subtables, Quality Assurance activities remaining.
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.
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.
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.
Better multi-window handling with overlay support and integration with shmif-server to nest/embed graphical subtasks.
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.
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.
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.
Mostly QA and synchronization with changes in libretro.
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.
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.
Multiple experiments exist out-of-source, with the aloadimage tool acting as a testing ground. No actual progress until 0.6/0.8.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Basic text management in place. Missing more advanced features like audio, video and binary blob management.
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.
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.