Introduction
In this post, I’ll propose Amadeus - a design for an experimental highly-distributed, extensible, and network-transparent windowing system that supports resolution-independence through the use of vector graphics technology, and scales from a single PC (or other device) to a large cluster of devices.
This will hopefully be achieved via the meticulous usage of compression, and adaptive data structures; the adoption of a multicast/broadcast architecture, and orchestration from federated or standalone Registrars.
My decision to write this proposal was inspired by interesting discussions with a friend regarding implementations of other systems (Display PostScript, NeWS, and the many window servers of Symbian OS); and reading various tirades against X11, plus documentation regarding various proprietary systems (especially Photon).
However, the system itself has a brand-new design (as far as I’m aware) – and probably plenty of stupid design mistakes that were rectified by others in the past…
High-Level Architecture
The Amadeus architecture consists of 4 main components:
- The Rendering Surface – responsible for accepting hardware events, and rendering graphics data received from Applications via private channels or network broadcasts.
- The Registrar – responsible for coordinating the activities of the rest of the architecture.
- Applications – either built directly against a library that generates vector graphics data, and sends it to the Rendering Surface; or against a ported GUI widget toolkit (or compatibility layer for an existing windowing system) designed to do so.
- Hardware Event Providers – responsible for collecting and dispatching hardware events.
These roughly fit together, like so:
Responsibility for font rasterisation and management is either directly accounted for by the Rendering Surface implementation, and a suitable rasterisation library (e.g. FreeType or MonoType iType) – in the case where text is embedded in SVG data, or by applications designed to deliver pre-rendered text as vector shapes and paths.
Descriptions of other window system architectures, such as Microsoft’s GDI and various successors, X11, Apple’s Quartz, QNX’s Photon, NitPicker, FreeDesktop.org’s Wayland, and variants of Display PostScript are best found elsewhere.
Authentication and Confidentiality
Authentication and confidentiality of signalling and graphical data network traffic is beyond the scope of this proposal – as other parties have more expertise in that area, and I feel that I cannot immediately improve upon existing designs. Those interested in such functionality should investigate IPSec (which should work with multicasting, according to this paper from Cisco), and SSL/TLS (or SSH) for private channels.
The Registrar
The Registrar announces its availability upon launch via network broadcasts (or multicasts); and tracks Rendering Surfaces, HWEPs and client applications interested in either listening for hardware events, or displaying windows on a per-machine, cluster, or network basis by unique name.
It also stores client configuration data (e.g. connected display resolutions, the characteristics of connected HIDs (keyboards, mice and game controllers), and preferred data structure widths), in addition to orchestrating the window management activities of machines within a cluster.
Whilst the intention is obviously to eventually support large-scale clusters and networks of “screens and machines”, with application windows freely distributed amongst them (in the case of X11-style invocation and display of applications installed on other machines); multiple Registrar instances (supporting multiple clusters or standalone PCs) shouldn’t conflict with each other, and it should always be possible for users to decide upon levels of isolation, and appropriate network topologies.
Multicast DNS (as implemented in Apple’s Bonjour/mDNSResponder, and Avahi), or D-BUS might be feasible technology options for implementing parts of this functionality.
The Rendering Surface
The Rendering Surface implementation accepts compressed SVG data from applications, and hardware events from HWEPs, received via either a private channel (e.g. a transient UDP socket with a port number known by the Registrar, a UNIX domain socket, or a platform-specific IPC mechanism), or a network broadcast/multicast transmission.
Instances thereof must register themselves using a unique name to the Registrar (and optionally specify a private channel), and accept any relevant events from Hardware Event Providers, such as mouse clicks and movements, and keystrokes.
The SVG data that applications generate should accurately render using any quality SVG implementation – regardless of its ultimate bitmap data destination (e.g. a raw framebuffer, or Qt’s SVG rendering widget), post decompression.
Compression Algorithms and Data Structures
Data structures used by Amadeus for signalling are designed to be extensible and easy to parse (explicitly identified using 64-bit field type IDs, and accompanied with content length fields); and capable of being dynamically resized to accommodate network connections with varying levels of quality (i.e. latency and bandwidth).
If so desired, it may be theoretically possible to adapt data structures from other protocols, to provide additional functionality – although in the case of some (e.g. the X11 Clipboard protocols), it would probably be a better idea to design new ones, in the long run.
Although it was originally intended that “plain” SVG 1.1 data be compressed according to the WBXML 1.3 specification from the Open Mobile Alliance, it should be possible to support alternative serialisations of an SVG data stream (e.g. transformed JSON), and additional compression algorithms (e.g. those implemented by ZLib/GZip) via the aforementioned extension mechanism.
An Open Source WBXML parsing and generation library (released under a variant of the BSD License, with a promotional clause), written in C++ is available from the Sybyx project on SourceForge. Although I haven’t attempted to use it (yet), I received the impression that its API is reasonably clean and well-designed.
Bilal Siddiqui’s DevX.com article also provides a rough idea of a conversion technique, and an archive containing a set of XML files in both encoded, and non-encoded forms.
I have attempted to register the SVG 1.1 XML Document Type Definition ID (-//W3C//DTD SVG 1.1//EN) with the OMA, using their online form – although the process failed, due to a configuration error of the Web server.
Compression – State of the Art
Whilst I’m unaware of other, entire window system architectures utilising SVG for drawing, the technology has been successfully utilised as a significant part of KDE’s Plasma family of desktop environments; for rendering icons in the AVKON/S60 user interface framework for Symbian OS (and its successors); and for a multitude of other applications.
However, most implementations tend to assume that graphics files are stored as plain text XML files within a local (or remote/removable) file system, and can be quickly accessed prior to rendering – which works well for most applications, but is likely to be extremely inefficient within Amadeus, due to its network-bound, distributed nature.
The most obvious solution to this problem would be to use one of the aforementioned compression techniques (or another) – which is reinforced by this paper (circa 2003) from the seemingly defunct developers of the X-Forge game development toolkit, concluding that their proprietary compression technology compares favourably to PNG and JPEG bitmaps, in terms of resulting file size.
X-Forge’s developers were also able to achieve a bitmap-equivalent level of apparent image quality for a static set of textured game graphics (and further size reductions when cramming all of their resources into a ZLib-compressed archive), in addition to resolution independence – although in the case of Amadeus, it is highly likely that graphics will consist of both vector widgets, and wrapped bitmap images (e.g. photographs, Web graphics, and pre-rendered widgets from applications built against non-native toolkits), which may affect efficiency.
From very brief testing with GZip’s -9 argument, I was able to compress a copy of the SVG file (exported from InkScape in “Plain SVG” format) corresponding to the architecture diagram to 1.00 KB (1,024 bytes), from 3.97 KB (4,075 bytes). The original, uncompressed version of the file, exported without optimisations to remove InkScape-specific metadata was 5.18 KB (5,314 bytes) in size.
As previously mentioned, I have not yet tested a WBXML implementation against these files, for comparison.
Bitmap Image Support
Through the use of data: URIs, and Base64-encoded image files, it is possible to embed bitmap graphics data into SVG content, so that the aforementioned common use cases (e.g. display of Web image content, and graphics from other windowing systems) can be supported.
This technique could be combined with a hybrid local-distributed image caching system that is integrated with the Registrar, delta encoding of SVG payloads, and checksum-based URIs for referencing extracted bitmap image data within the cache.
More sophisticated approaches to this problem are described in a technical reference document from NoMachine, related to their NX unicast display/window sharing architecture (which in turn is closely entwined with the X11 architecture).
Conclusion
In isolation, distributed windowing systems; multicast architecture-based distributed systems in general; and vector-based GUIs are nothing new, conceptually. What Amadeus brings to the table is an amalgamation of these disparate concepts in the form of a modern, flexible design, that should be suitable for supporting multiple high-resolution displays, and users with wildly varying requirements.
Whilst I’ve left issues related to high-performance rendering of 3D graphics and video content, latency, security, and various other architectural aspects unresolved; I’ve hopefully provided an interesting starting point for debate on the design of such systems.
