Alcinoe is an open-source component library, distributed under a permissive licence, for Delphi and C++Builder, maintained on GitHub by Zeus64. It covers ground that the VCL and FireMonkey RTL leave to third parties: a GPU-accelerated video player, a WebRTC wrapper, native iOS and Android edit controls, a dual-mode JSON/BSON parser, a MongoDB client with connection pooling, an ImageMagick wrapper, and a collection of FireMonkey controls that sidestep the stock rendering pipeline entirely. The library built its reputation on Rio (10.3.3) and Sydney (10.4.2), and has since tracked each Embarcadero release. At the time of writing, it is fully compatible with Delphi 11.1 Alexandria and Delphi Athens 12.3
Getting Alcinoe into a project
Installation hinges on one question: do you require design-time support for Alcinoe’s visual controls? If not, skip the BPL entirely. Add {alcinoe_rootdir}\source to the project’s library search path and you are done. Every non-visual component, including the parsers, database clients, and string utilities, compiles from source without registering anything
If you require design-time support, the path is slightly longer. Open Component > Install Packages in the Delphi IDE, browse to the BPL that matches your version (for example {alcinoe_rootdir}\lib\bpl\alcinoe\Win32\alexandria\Alcinoe_alexandria.bpl), install it, and then still add {alcinoe_rootdir}\source to the search path. The BPL registers the components; the source directory is what the compiler finds when it compiles your project
Alcinoe ships optional patches to the Embarcadero RTL sources. If you want them, navigate to {alcinoe_rootdir}\embarcadero\, pick the subdirectory for your version, and run update.bat. The script expects GIT in the PATH and assumes a default Embarcadero install location. It fetches the original RTL source and applies the patches. Once done, add that patched source directory to your project's search path so the compiler picks it up ahead of the read-only copy in the Embarcadero installation tree. None of this is required for getting started; it only matters if you encounter bugs or unexpected behaviour that the patches resolve
Android and the D8 desugaring proxy
Several Alcinoe components (WebRTC, ExoPlayer-backed video) depend on Java libraries that utilise Java 8 language features. The Android toolchain that ships with older Delphi versions uses dx.bat for DEX conversion, which cannot handle those bytecodes on API levels below 26. The solution is desugaring, which D8 handles automatically when invoked directly. Alcinoe provides a proxy script at {alcinoe_rootdir}\tools\D8Proxy\dx.bat that forwards calls from the Delphi build system to D8, making desugaring transparent. Replace the original dx.bat in your Android SDK build-tools directory (typically C:\SDKs\android\build-tools\30.0.3\) with this proxy. Embarcadero tracked the underlying issue at RSP-24155; later versions of the SDK tools addressed it directly, so verify whether your current toolchain still requires the workaround
The FireMonkey rendering issue and Alcinoe's solution
FireMonkey’s default paint cycle becomes a bottleneck in scroll-heavy UIs. A single TRectangle with rounded corners can take around 3 ms to repaint because the stock implementation recalculates the path and fill colour on every frame. With 20 such controls visible, that adds up to 60 ms per frame pass, which limits the effective frame rate to well below the threshold for fluid scrolling
Alcinoe resolves this with a GPU-resident buffer per control. The first paint renders the control to a TTexture stored in GPU memory. Subsequent repaints blit that texture instead of re-executing the paint algorithm. The measured result on the same rounded rectangle drops from around 3 ms to around 0.1 ms. Beyond the buffering, Alcinoe replaces OpenGL path-drawing for basic shapes with native Android and iOS drawing APIs, bypassing the quality/performance trade-off to optimise rendering. The relevant controls are TALRectangle, TALCircle, and a set of improved layout containers including a ScrollBox and TabControl
TALJsonDocument: DOM and SAX in one type
TALJsonDocument is Alcinoe’s JSON and BSON parser. It supports two traversal modes. DOM mode builds an in-memory object tree, providing random access to any node at the expense of memory proportional to the document's size. SAX mode fires events as the parser reads each token without retaining any tree, which is the correct choice when you need to filter a large document and retain only a handful of values. DOM parsers in Delphi (DBXJSON, SuperObject, and the others) are typically three to five times slower than a SAX approach for the same content, because each node allocation carries object-creation overhead in addition to the parsing work itself
The type follows the identical node-navigation pattern as TALXMLDocument. A minimal DOM read is as follows:
MyJsonDoc.LoadFromJSON(AJsonStr, False {dom mode});
MyJsonDoc.ParseOptions := [poAllowComments];
// read scalar values
ShowMessage(MyJsonDoc.ChildNodes[‘name’].ChildNodes[‘first’].Text);
ShowMessage(IntToStr(MyJsonDoc.ChildNodes[‘_id’].Int32));
// iterate an array
for I := 0 to MyJsonDoc.ChildNodes[‘contribs’].ChildNodes.Count - 1 do
Writeln(MyJsonDoc.ChildNodes[‘contribs’].ChildNodes[I].Text);For SAX mode, assign an anonymous procedure to OnParseText before calling LoadFromJSON with the second argument set to True. The callback receives the node path, name, value, and a TALJSONNodeSubType that identifies the JSON type (string, integer, float, boolean, and so on). This mode produces no heap allocations for nodes, therefore it scales to arbitrarily large documents without exhausting the memory budget
TALJsonDocument also reads and writes BSON natively; pass True as the BSON flag to LoadFromFile or SaveToFile. A second variant, TALJsonDocumentU, utilises UnicodeString (UTF-16) internally instead of AnsiString (UTF-8) for contexts where the surrounding code operates entirely in Unicode
MongoDB client and connection pooling
Alcinoe’s MongoDB driver covers the common query operations and handles connection pooling natively. The simple client, TAlMongoDBClient, opens and closes a single connection per operation. The pooled variant, TAlMongoDBConnectionPoolClient, maintains a set of live connections and distributes one to each calling thread from the pool, returning it when the call completes. This model prevents multiple threads from blocking one another during connection setup, which is crucial whenever background workers are querying the same database simultaneously. For tailable cursors on capped collections, TAlMongoDBTailMonitoringThread monitors for new documents and fires a callback when they arrive, which is the standard pattern for log streaming or change notification without polling
Other components worth knowing
ALVideoPlayer renders video to a TTexture rather than an overlay window, enabling other FireMonkey controls to sit above it in the Z-order. The Android backend utilises ExoPlayer, which adds DASH, HLS, and SmoothStreaming support beyond what Android’s built-in MediaPlayer handles. The iOS backend uses AVPlayer with equivalent HLS support
TALWebRTC wraps the WebRTC stack for peer-to-peer audio and video. It does not require a browser or a plug-in, and the connection traverses NAT through the standard ICE/STUN/TURN negotiation that the underlying library manages
TALStringList replaces TStringList’s AnsiCompareText-based sort with a locale-independent ordinal comparison and a quicksort that is up to 10x faster on large lists. The hashed variant, TALHashedStringList, adds an internal hash table for O(1) lookup at the expense of slightly higher overhead on small lists. Note that TALStringList is an 8-bit AnsiString list, not a Unicode one; it fits well in server-side code where UTF-8 is the working encoding and raw throughput is more important than locale-aware comparison
On 64-bit Windows, the FastCode heritage that gave many of Alcinoe’s string routines their speed advantage (mostly hand-written x86 assembly) does not carry over. The Win64 builds fall back to the Pascal implementations, which run noticeably slower on string-intensive workloads. The demo\ALStringBenchMark project allows you to measure the gap on your hardware before committing to a 64-bit build where string throughput is a bottleneck
The full source is available at github.com/Zeus64/alcinoe