Feature Comparison: XiboPlayer v0.7.9 vs Upstream Players

Last Updated: 2026-03-30 Our Version: v0.7.9 (SDK v0.7.9, PWA v0.7.9, Electron v0.7.9, Chromium v0.7.9)

Compared against:

• xibo-layout-renderer v1.0.24 (npm, 2026-03-30) — rendering library used in Xibo's Electron/ChromeOS players
• xibo-communication-framework v0.0.7 (npm, 2026-03-30) — upstream XMR client (replaced by our native implementation)
• Xibo for Windows v4 R407 (C#/.NET + CEF, 2026-03-30) — the only actively maintained upstream player
• Arexibo v0.3.2 (Rust + Qt, 2026-03-30) — PDF rendering, RPM/DEB packaging, duration fixes

Executive Summary

Overall: 100% feature parity across all areas. Unique capabilities: REST transport, protocol auto-detect, persistent durations, canvas regions, download resume, multi-display sync (mirror + wall mode), playback control, complete kiosk OS

Performance Comparison

Electron vs Chromium (v0.7.9 production profiling)

Both players run the same PWA. Profiled in production kiosk fullscreen mode playing identical content on the same machine (Fedora 43, Wayland, Intel UHD 630 GPU).

Key findings:

• CPU parity — both players at 4-8% in production fullscreen mode with GPU-accelerated rasterization and compositing.
• Continuous automated monitoring — CPU per process type (main, GPU, renderer, network), PSS memory, file descriptors, GPU DRM render time and iGPU utilization are tracked every 60 seconds. Zero memory growth confirmed over extended production runs.
• GPU auto-detection — on hybrid GPU systems (Optimus), the player selects the display GPU automatically. Render-only GPUs are skipped when they can't share framebuffers on Wayland.
• Both players survive CMS outages — cached layouts keep playing offline.

Where XiboPlayer is Better

1. Dual transport (SOAP + REST) with idempotent cache — only player with native JSON/REST communication and transport-agnostic caching (files cached via XMDS or REST are served identically)
2. ETag caching — HTTP 304 for unchanged responses
3. 4x faster downloads — parallel 4-chunk downloads with dynamic sizing
4. Progressive streaming — Service Worker Range request support
5. Instant layout replay — element reuse (<0.5s)
6. Better memory management — per-layout blob URL lifecycle tracking
7. PDF multi-page cycling — PDF.js with timed page transitions (XLR and Windows lack this)
8. Better dayparting — daily/weekly/monthly recurrence with ISO day-of-week
9. Cross-platform — any device with a modern browser
10. Zero installation — PWA: just open a URL
11. Offline resilience — IndexedDB auto-fallback + queue barriers
12. RPM/DEB packaging — native Linux packages with auto-update repos
13. Bootable images — ISO, raw, QCOW2 for x86_64 and aarch64
14. Player-agnostic kiosk — alternatives system for swapping players
15. Multi-display sync with choreography — BroadcastChannel (same-machine) + WebSocket relay (LAN). Mirror mode or wall mode with layoutMap. <8ms sync precision. 12 choreography effects for dramatic cascading transitions (diagonal, wave, center-out). Token-authenticated relay, syncGroupId isolation, offline LAN sync, stats delegation. Standalone xiboplayer-relay CLI. Works on both Electron and Chromium. Windows player has zero multi-display sync code (confirmed by source audit); XLR and Arexibo have none either. Full guide
16. Playback control — keyboard shortcuts and timeline click-to-skip (disabled by default, enabled via controls config)
17. CMS Management API — 77-method REST client for full CMS v4 API
18. SSL cert relaxation — opt-in relaxSslCerts for media streams with self-signed certificates
19. Configurable log levels — config.json logLevel for runtime log control
20. Complete XMR implementation — native XmrClient with generic action dispatch handles all 14 CMS actions; upstream framework only dispatches 5 (the rest are silently dropped). Zero dependencies vs 68KB luxon
21. XMDS download caching — XMDS signed URLs rewritten to local proxy mirror paths, eliminating CORS failures and enabling ContentStore caching for all XMDS content (layouts, media, fonts, bundles). X-Cms-Download-Url header enables XMDS-only CMSes to use the full cache-through pipeline
22. 1629 automated tests — 49 test files covering all SDK packages. Windows player has zero tests, XLR has zero tests, Arexibo has only 2 tests. XiboPlayer is the only Xibo player with a meaningful test suite
23. Wayland hardware GPU acceleration — GPU auto-detection selects the display GPU on hybrid systems. GPU rasterization flags reduce Chromium CPU from 91% to 5%. Filed upstream as electron#50455
24. Offline-first playback — Content store serves cached layouts and media during CMS outages. Download manager race conditions fixed (commit-before-response, key format unification)
25. PSS-based memory monitoring — Proportional Set Size tracking distinguishes real memory cost from shared page inflation. Per-process type detection (gpu/renderer/browser/server) with 48h overnight profiling

Upstream Audit Results (2026-03-18)

Code analysis of upstream repositories confirmed:

• Windows player: zero multi-display sync code in the entire codebase. No sync manager, no relay, no choreography. The ~50-100ms figure previously cited was theoretical — there is no implementation at all
• Windows player: zero automated tests. No test project, no test runner, no CI test step
• XLR (xibo-layout-renderer): zero automated tests. The npm package ships with no test suite
• Arexibo: 2 automated tests only (basic XMDS parsing)
• XiboPlayer: 1625 tests across 49 test files, covering core, renderer, cache, schedule, xmds, xmr, stats, settings, sync, and crypto packages

What Competitors Have That We Do Not

Features present in upstream players that XiboPlayer does not implement:

1. RS-232 serial port — Windows and Arexibo support hardware serial commands for controlling displays, projectors, and matrix switchers. Not available in the browser sandbox
2. PowerPoint rendering — Windows player renders .pptx natively via COM automation. Browser-based players cannot render PowerPoint
3. Geo-fenced scheduling (CMS-side coordinates) — Windows player uses CMS-provided GPS coordinates for geo-fence evaluation. XiboPlayer implements geo-fencing via browser Geolocation API + Google API + IP fallback chain, which covers the same use case differently
4. Schedule criteria tags — Windows player supports CMS tag-based schedule criteria filtering. XiboPlayer evaluates 5 metrics + weather + custom display properties but does not yet support tag-based criteria
5. Interrupt/share-of-voice hourly algorithm — Windows player implements the CMS hourly share-of-voice distribution algorithm for interrupt layouts. XiboPlayer implements interrupt interleaving but uses a different distribution approach
6. AXE/SSP ad integration — Windows player has hooks for Broadsign AXE and SSP ad server rotation. XiboPlayer has an isSspEnabled stub but no active ad server integration
7. Cycle playback with play count — Windows player supports per-widget play count limits within sub-playlist cycle mode. XiboPlayer supports sub-playlist cycle playback and playCount but the exact per-cycle reset behaviour may differ