In-memory and persistent caches
| Cache | Configuration/query | Scope |
|---|---|---|
| General in-memory | gx3de_engine_cache_stats | Per engine. |
| Persistent mesh | gx3de_engine_set_mesh_cache_root / gx3de_engine_disk_cache_stats | Filesystem cache root; can be disabled with NULL. |
| Persistent repeat analysis | gx3de_engine_repeat_cache_stats | Independent repeat sub-cache. |
| Persistent scientific | gx3de_engine_set_scientific_cache_root / gx3de_engine_scientific_cache_stats | Scientific import/derived cache path. |
A caller should set a cache namespace when Session/project isolation matters. Cache fingerprints are bounded and source-aware; they are performance/provenance helpers, not replacements for logical Session IDs.
Generic jobs
Jobs prepare mesh import, mesh LOD, STEP import and B-Rep→mesh conversion. Lifecycle is prepare → start → poll/wait/events/progress → take result → destroy. Events carry sequence/state and progress in permille when the capability is present. Failure text follows the standard UTF-8 capacity/required-bytes query contract.
Update() operations cannot be interrupted inside the third-party call. Jobs check cancellation before/after bounded stages. GX-TXT therefore runs renderer/import work in an isolated process when robustness requires killing an uninterruptible backend.Renderer limits
| Resource | dev-40 boundary / behavior |
|---|---|
| RGBA target buffer | 256 MiB maximum; at most 16,384 pixels per axis. |
| Display triangles | Effective graphics-policy budget, range 1,000…4,000,000; scene-wide accumulated display geometry. |
| Scientific render preflight | At most 1,000,000 source points and 1,000,000 source cells for display path; exterior/result limits also apply. |
| Scientific sphere glyphs | 100,000 dev-40 safety cap, additionally constrained by display-triangle budget. |
| Vector glyphs | Presentation descriptor upper limit 20,000. |
| Field line/pathline output | Up to 1,000,000 output points per descriptor; per-step/temporary-memory limits are explicit. |
| View clip planes | Eight descriptors exist, but current VTK renderer accepts at most six active clipping planes total; an enabled clip box consumes six. |
| Markers / measurements | Up to 10,000 each per scene for one render. |
| Gizmos | Up to 64 per view for one render. |
| B-Rep display tessellation | 2,000,000 triangles / 256 MiB output in documented renderer path. |
Graphics resource accounting
OpenGL GPU consumption is currently a conservative estimate. gx3de_target_render_resource_info_get distinguishes estimated, measured and unavailable accounting. An explicit GPU budget rejects a render preflight with GX3DE_RANGE before backend resource creation. This is not an exact VRAM meter.
Thread ownership
The target and its OpenGL context belong to the thread that created the target. Rendering from another thread is rejected. Scene/view/target/viewport mutators and pixel readers follow the same owner-thread expectation. Background jobs are the supported path for bounded asynchronous preparation.
Linux renderer process constraints
The packaged OpenGL path requires an X display, including headless targets. DISPLAY must be valid; inherited indirect GLX is rejected. GX-TXT’s adapter can launch a child process with Mesa software rendering and enforce address-space plus sampled RSS limits. These external process limits are not automatically enforced on an arbitrary in-process C consumer.