When STL is not enough: building predictable real-time graphics systems
Sign up for Developer monthly newsletter
Join thousands of developers around the globe who receive latest news and updates from our monthly curated newsletter.
Sign upCome for support, stay for the community
Get support from experts, connect with like-minded developers, and access exclusive virtual events.
Join Developer DiscordCo-written with Kashyap Rajpal and Mauricio Maurer.
Real-time graphics applications operate under strict performance constraints where unexpected allocations, memory fragmentation and container growth can introduce costly frame-time spikes. QRE is an open-source C/C++ support library designed to help graphics developers maintain predictable performance through fixed-capacity containers, allocation-aware utilities and SIMD-optimized math for Windows, Android and Linux workloads.
Why STL alone is not enough for real-time graphics
The C++ Standard Template Library (STL) is one of the strongest foundations in modern C++ development. It provides portable, well-tested containers, algorithms, strings, and utilities that are sufficient for many applications.
But real-time graphics code operates under a different set of constraints: strict frame budgets, predictable memory behavior, cache efficiency, and low overhead on performance-critical paths. In those environments, STL's general-purpose design can leave important gaps.
For example, frame-time budgets are strict, and heap allocation is a liability on the hot path. When std::vector fills its current capacity, a typical implementation allocates a new buffer, move-constructs existing elements into the new location, then frees the old buffer. That can mean a heap allocation, a heap deallocation, an O(n) relocation of existing elements, and the memory transfer cost of reading and writing the container's contents — all triggered mid-frame by a single push_back. The timing is non-deterministic: it depends on how full the container happens to be, what the allocator finds in the free list, and how many elements must be relocated.
On a render loop with a hard frame-time budget, this kind of unpredictable spike is unacceptable.
Beyond individual container growth, repeated dynamic allocation can degrade the heap over time. Each allocate/free cycle can leave gaps in the allocator's free list, causing memory fragmentation. A long-running application that allocates and frees objects of varying sizes may end up with heap memory that is technically available but scattered across non-contiguous blocks. The allocator may need to search longer for a suitable fit, consecutive allocations may land at dispersed addresses, and cache-line reuse can degrade.
Fixed-capacity containers and allocation-aware utilities sidestep these problems by making capacity and memory layout explicit. With capacity known up front, there is no reallocation, no heap round trip, and no fragmentation on the hot path. These are common requirements in real-time graphics code, but the STL does not provide them directly.
STL also does not include built-in graphics math support — vector types, matrix operations, quaternion utilities, or SIMD-friendly abstractions. As a result, real-time graphics teams often build their own support libraries for fixed-capacity containers, memory utilities, and optimized math.
That is the gap QRE is designed to fill.
Introducing QRE
QRE (pronounced "core") is a C/C++ support library purpose-built for real-time graphics: fixed-capacity containers, low-level memory primitives, and 3D vector and matrix math optimized via SIMD – ARM NEON on mobile and SSE on x86 – behind deterministic, allocation-aware APIs designed for the real-time path.
Inside Qualcomm Technologies, QRE has served as the shared foundation for graphics and real-time systems work across Windows, Android, and Linux. Rather than keep rebuilding these primitives per-project, we're open sourcing the library itself – and we'd love your feedback and contributions.
Benefits
QRE provides practical building blocks for real-time graphics applications where predictable performance, portability, and low overhead matter.
Predictable memory behavior
- Fixed-capacity containers and allocation-aware utilities help avoid unexpected heap activity on performance-critical paths.
- Pool, arena, and relative-pointer utilities support data layouts commonly needed by real-time systems and asset pipelines.
Optimized math and portability
- Vector and matrix math utilities are designed for graphics workloads and optimized across mobile and desktop targets.
- A common SIMD abstraction enables NEON, SSE, or scalar implementations behind a consistent API.
Reusable graphics-framework utilities
- Common support for image loading, texture formats, configuration files, logging, paths, and threading reduces the need to rebuild the same infrastructure in every graphics project.
- These utilities are useful for applications, samples, asset tools, test harnesses, and other components around a graphics framework.
QRE has minimal dependencies and can be easily integrated into existing projects.
Image and Configuration Utilities
QRE includes support for loading and exporting images used by graphics applications and supporting tools, including common formats such as PNG, JPG, DDS, and EXR, along with texture-format metadata for compressed and depth/stencil formats.
These utilities support various features including texture loading, texture export, asset processing, testing, and configuration in a graphics framework.
Testing
QRE includes various unit testing through CTest to help ensure stability and prevent regressions as the project evolves.
Connect with us
We look forward to your input, whether that is a bug report, feature request, contribution, or question about how QRE can fit into your project.
- Issues: https://github.com/qualcomm/qre/issueshttps://github.com/qualcomm/qre/issues
- Contributing guide: https://github.com/qualcomm/qre/blob/main/CONTRIBUTING.mdhttps://github.com/qualcomm/qre/blob/main/CONTRIBUTING.md
Closing Remarks
QRE has helped power real-time graphics development at Qualcomm Technologies for years, and we're excited to bring it to the open-source community.
Thanks to all the current and past contributors who helped shape this library, including:
|
Alan Hickman |
Francesco Giancane |
Gauthier Germain |
|
Gayatri Dhore |
Janardhan Haryadi Ramesh |
Jeffrey Moguillansky |
|
Kashyap Rajpal |
Luka Pandza |
Marcos Ibanez Matles |
|
Mark Feldman |
Mark Golden |
Mauricio Maurer |
|
Rommel Bhargava |
Ronan Quill |
Veera Ajay Kumar Karanam |
|
Viggo Falster |
Wade Lutgen |
|


