Arcan is a powerful development framework for creating virtually anything between user interfaces for specialised embedded applications all the way to full-blown standalone desktop environments.
At its heart lies a robust and portable multimedia engine, with a well-tested and well-documented interface, programmable in Lua. At every step of the way, the underlying development emphasises security, performance and debugability guided by a principle of least surprise in terms of API design.
See the Videos page for videos from projects built using the engine as a main component.
For a high-level presentation, please refer to this video:
The slides can also be viewed separately:
Among the more uncommon features in Arcan, we can find:
- A multi-process way of hooking up dynamic data-sources (“frameservers”) such as online video streams, capture devices, and even other running programs as programmable objects for both graphics, audio and input. This permits aggressive privilege separation for what has historically been error-prone and security challenged tasks.
- Capable of being its own compositor, display server and window manager at the same time. There are two build outputs, arcan and arcan_lwa (‘lightweight’). Arcan uses the underlying hardware to present aural and visual information and obtains input from external devices. arcan_lwa re-uses most of the same codebase and API, but uses arcan for input and output.
- Built-in monitoring and crash-dump analysis. The engine can serialise vital internal state to a Lua script (“crash dump”) or to another version of itself periodically (“monitoring”) to allow external filters and tools to be written quickly in order to track down bugs or suspicious activity.
- Fallbacks — Should the running application fail due to a programming error, (which can, of course, happen to any moderately complicated application), the engine will try to gracefully hand-over external data sources and connections to a fallback application that adopts control and tries to recover seamlessly. Should the engine crash, the processes in (1) can reconnect or migrate to another display server and retain most of its internal state.
- Fine-grained sharing — Advanced tasks that are notably difficult in some environments, e.g. recording / streaming controlled subsets of audio and video data sources (including ‘desktop sharing’) requires little more than a handful of lines of code to get going.
The primary development platforms are Linux and BSDs (Free;Net;DragonFly so far), but releases are actively tested on Mac OS X (but with less fancy features) and, up until recently, Windows.
While it works under various display and input subsystems like SDL, a primary goal is for the framework applications to run with as few layers of ”abstraction” and third party dependencies as possible.
Envisioning its role as a Display Server:
Think of an X11-like model where you have a Server, a protocol and a number of clients. The server is responsible for controlling hardware and routing shared resources like input samples or clipboard contents. The clients react on input and provides content. The ‘protocol’ regulates how the clients and server communicate. A special client (Window Manager, WM) takes some control over window management (client drawing properties, like position and size), optionally attaching features such as decorations (border, titlebar, …).
With this model in mind, follow these steps:
- Divide clients into different privilege levels. Some clients should get access to receiving copies of screen contents, manipulating the clipboard, or receiving global keyboard input; others don’t even get to use the GPU or create multiple windows.
- Move the WM INSIDE the Server Process and give it access to an API with more advanced- and privileged- features than what is offered over the protocol. This cuts down on protocol complexity, and removes a number of intractable synchronisation problems.
- Add a scripting interface for the WM. This drastically reduces the “barrier to entry” for developers and advanced users to tune and reconfigure.
- Extend the feature scope to include audio. There are way more similarities between audio and video processing than there are differences. This step cuts down on systemic complexity by solving connection setup and IPC, buffer transfers, privilege separation, user controls etc. once. It also makes the WM more powerful.
- Remove the ‘protocol’ parts entirely. Replace it with a lock-step API (updates require recompilation against the display server itself) in order to be able to more quickly adapt- and absorb- new features without suffering from “protocol extension hell” or the problems that come with maintaining backwards compatibility to multiple versions.
Point 5 creates real problems for clients of course, who’s going to use it if that is the case?. To combat this, the following steps are taken:
- Add special bridging clients that the Window Manager scripts can take extra consideration for in order to support display server protocols. This is how old X clients will be enabled, as well as newer Wayland- capable clients. This approach leads to a more ‘micro-kernel’ like modularity.
- Maintain custom backends that use said API for a select few targets that are easy to keep in lock-step and that would benefit from reduced protocol overhead. Due to the design of the segmentation API, these are typically self-contained applications like CLI- tools, Virtual Machine Monitors, Emulators, Games, Web Browsers and so on.