The crash in #358 was not the out-of-memory itself. wgpu reports OOM as
recoverable and the app already installs a handler that logs and keeps
the session alive. What killed the process was what happened next:
create_buffer_init maps the new buffer unconditionally, and mapping the
invalid buffer an OOM device returns panics. That panic unwinds through
iced's main-thread redraw, trips the wgpu-hal swapchain assertion in a
destructor, and becomes a non-unwinding abort -- no chance to autosave.
Every allocation whose size scales with the drawing now goes through
src/scene/pipeline/gpu_upload.rs, which creates the buffer unmapped and
fills it with Queue::write_buffer. A failed allocation then surfaces as a
validation error on the write, which reaches install_gpu_error_handler
and degrades the frame -- exactly what that handler's comment promised:
"A bad frame must degrade, not end the session."
Converted: block-wire vertices and instances, the wire const storage
buffer, all three wire-arena allocators, face3d vertices and instances,
block-text instances and text vertices, both hatch backends, and the
silhouette buffers. mesh_gpu already allocated this way, which is why the
mesh path never produced this panic; the rest now match it.
No mapped_at_creation:true remains in the renderer. The create_buffer_init
calls left are fixed-size or bounded-small -- uniforms, the viewcube's
static geometry, per-image and per-wipeout quads -- where an allocation
failure is not a realistic outcome.
Two trade-offs worth stating:
* write_buffer stages through a copy, which mapping at creation avoided.
Chunking bounds that transient cost, and the measured block-wire
upload got faster with chunking, not slower.
* `queue` had to be threaded through the wire, face3d, text and hatch
builders and their callers. Mechanical, but it widens the diff.
This touches every upload path, so it needs a visual check against a real
drawing before it goes upstream.
Co-Authored-By: Claude Opus 5 <[email protected]>
max_buffer_size is an API validation limit, not physical VRAM. NVIDIA
reports several GB of it on a 2 GB card, so sizing a chunk from it
produces buffers larger than the whole device. That is the same bug as
#203 (mesh_gpu), #358 (face3d_gpu) and the block-wire vertex buffer:
rediscovered three times because each upload path spelled the budget out
for itself.
mesh_gpu.rs was the only site that clamped the result. Move that clamp
into src/scene/pipeline/gpu_budget.rs and route every allocating path
through it, so a new upload path cannot reintroduce the mistake by
copying one of the unclamped expressions.
Five sites had no clamp at all: text_gpu (block-text instances),
wire_gpu (block-wire instances), and face3d_gpu (vertices, instances,
and upload_chunks).
Three behaviour changes worth noting:
* Silhouette chunks were capped at a private 64 MiB constant and now
use the shared 32 MiB budget.
* The storage-hatch chunk limit was the minimum of two device limits,
both of them validation figures; it is now also capped by the
budget. The `*_fits` predicates next to it are genuine "would wgpu
reject this" checks and are left alone.
* mesh_gpu's instanced path used the unclamped ceiling to decide
whether a mesh fits in a single buffer, which would still admit a
multi-GB allocation. It now uses the clamped budget, so a few more
meshes take the chunked path.
OCS_GPU_CHUNK_MIB overrides the cap. Raising it above the real VRAM is
the cheapest way to force an allocation failure and check that the
renderer degrades instead of aborting.
Co-Authored-By: Claude Opus 5 <[email protected]>
BlockWireGpu::from_wires built one unbounded vertex buffer per
(source_id, mesh_edge) group. On a block-heavy drawing that reached
~505 MiB in a single create_buffer_init, which fails on a 2 GB card;
wgpu then returns an invalid buffer and the unchecked
get_mapped_range_mut() inside create_buffer_init panics.
The instance buffer in the same function was already chunked. Convert
the vertex buffer the same way, matching the solid-mesh chunking in
mesh_gpu.rs (#203) and the fill chunking in face3d_gpu.rs (#358),
including mesh_gpu.rs's clamp: max_buffer_size is an API validation
limit, not physical VRAM, and NVIDIA reports several GB on a 2 GB card.
Chunk sizes are rounded down to a multiple of 6 so a segment's quad
never straddles two buffers -- the shader derives its corner from
vertex_index % 6 and every draw restarts that counter at zero.
Instance buffers are hoisted out so they are built once and reused
across vertex chunks instead of re-uploaded per chunk.
Co-Authored-By: Claude Opus 5 <[email protected]>
Refresh stale depth bounds after geometry edits, allow orbiting through camera poles, and preserve hidden-line occlusion for selected solids.\n\nFixes #957
Model space appearance now follows the active UI theme instead of a
hardcoded dark background. Canvas mode is user-selectable (Match Theme /
Classic CAD Dark / Custom RGB), with matching controls for the paper
sheet and desk surround backgrounds and grid opacity.
Implements industry-standard CAD system variables, all settable via
command name, SETVAR, and the Options dialog:
- COLORTHEME (0/1 dark/light UI scheme, preserves custom palettes)
- COLORSCHEME (interactive named-theme selection)
- BACKGROUND (THEME/CLASSIC/DEFAULT/DESK presets, RGB triplets)
- SELECTIONAREA, SELECTIONAREAOPACITY (translucent marquee fill)
- WINDOWSAREACOLOR/WINDOWAREACOLOR, CROSSINGAREACOLOR (ACI or theme)
- SELECTIONEFFECT, SELECTIONEFFECTCOLOR (GPU highlight pass, driven by
selection_generation invalidation — no retessellation)
- SELECTIONPREVIEW (bit 0 = idle rollover, bit 1 = in-command hover)
- GRIPSIZE, GRIPCOLOR, GRIPHOT, GRIPHOVER (grip overlay styling)
parse_power accepted a single exponent (`unary ('^' unary)?`), so a
chained power stopped after the first `^`. The remaining `^2` was left
unconsumed, and eval_to_string's embedded-expression scan then handed it
back as literal text: typing `2^3^2` into a coordinate or distance field
produced the string "8^2" rather than 512, and `2^3^2+1" produced "8^3".
Recurse into parse_power for the exponent so `2^3^2` reads as
`2^(3^2)", the standard right-associative meaning, and the whole
expression is consumed.
DIMAUNIT 4 is Surveyor's units, but format_angular_value matched only
0-3 and let 4 fall through the catch-all to decimal degrees. An angular
dimension in a drawing authored with surveyor units therefore read as
plain degrees, while AUNITS 4 in the same drawing writes a bearing for
the coordinate readout — the two disagreed on one angle.
Format the bearing from the dimension's own DMS path so it carries
DIMADEC, DIMAZIN and DIMDSEP, quantise before picking the quadrant so a
value just short of a cardinal does not quote a quarter turn, and offer
the option in the dimension-style dialog.
The Properties panel reads and writes ACAD_DSTYLE overrides for all three
dimension colours (DIMCLRD 176, DIMCLRE 177, DIMCLRT 178), but the
renderer consulted the override only for DIMCLRD and took DIMCLRE/DIMCLRT
straight from the dimension style. Editing 'Text color' on a dimension
therefore showed the new colour in the panel while the drawing kept
rendering the inherited style colour — which for the common
DIMCLRT = ByLayer default is the layer colour. (#898)
Route all three through one helper so the renderer and the panel read the
same value.
format_engineering split feet from inches before rounding to DIMDEC, so a
remainder that rounds up to a full foot printed out of range: 35.999" at
two decimals read 2'-12.00" instead of 3'-0.00". A magnitude that rounded
away to zero also kept a lone minus sign.
Round on the decimal grid first and split afterwards, matching the carry
handling already used by format_architectural and format_fractional.
Scene.selection was Rc<RefCell<SelectionState>> (31 fields, ~1.6KB
with poly_points) cloned deep per view_main per pane via
(*sel_ref).clone() at view/mod.rs:760. Replace with
Arc<RefCell<SelectionState>> (Arc::new(RefCell::new(...)) at
scene/mod.rs:1436,1868), SelectionCanvas holds Arc<RefCell> and
selection_overlay takes Arc<RefCell> (overlay.rs:365,415),
view_main does Arc::clone(&tab.scene.selection) (atomic bump)
instead of deep clone. sel_ref stays borrowed for field reads
(vp_size etc.).
Bench (release, n=5000): SelectionState::clone 39-68ns (64pts) /
11-22ns (0pts) vs Arc::clone 7ns — 5-9x on the hot path.
Tests:
- selection_is_arc_not_refcell: asserts type_name contains Arc
- bench_selection_state_clone / bench_selection_arc_clone / bench_selection_state_clone_empty (ignored, release)
