8cd0d46d58
* Zoom and pan regenerate in the background instead of freezing the window A rebuild that only the view asks for (a new 2x zoom band, a pan out of the built area) now runs on a worker thread while the canvas keeps drawing the previous display list, scaled by the view uniform. The worker builds the list, converts it to vertex data and creates the GPU buffers, so the frame that swaps it in only swaps buffers. One build runs at a time; a result from an older drawing revision is dropped. Edits, the first build and the web build (no threads) still rebuild synchronously. ZOOM no longer calls touch(): it changes the view, not the drawing, and the bumped revision made every typed zoom a full blocking rebuild (wheel zoom never did). REGEN, REGENALL and layout switches still touch. ui.screenshot waits (up to 6 s) for a background rebuild so agents capture the new view; ui.inspect perf reports "building". On a hatched 12k-entity DWG (~340k primitives) the longest UI stall per zoom went from 2-4.5 s to 26-64 ms. Also: cargo fmt of a comment in engine/src/prompt.rs that was failing the fmt gate on main. Co-Authored-By: Claude Opus 5.5 <[email protected]> * Cancel a background rebuild when the view moves on A view that needs a different display list now cancels the build in flight and starts one for itself, instead of waiting for the outdated build to land and only then starting the next. A long scroll through many zoom bands builds only for where it stops: the list lands about one build after the last step (2.0-2.3 s on a hatched 12k-entity DWG) instead of up to two, and an outdated build no longer keeps a core busy. cadcraft_render::Options gains `cancel` (an Arc<AtomicBool>); a set flag stops the build at the next entity (block contents included) and the hatch sweep at its next pattern line, returning a partial list the caller discards. The canvas's Job sets its flag when dropped, so replacing or dropping a job cancels it; a cancelled worker sends nothing. Co-Authored-By: Claude Opus 5.5 <[email protected]> * cargo fmt: crates/doc/src/dynblock.rs (fails the fmt gate on main) Co-Authored-By: Claude Opus 5.5 <[email protected]> --------- Co-authored-by: Claude Opus 5.5 <[email protected]> Co-authored-by: Brandon Thomas <[email protected]>
3.8 KiB
Hardware parity
Last reviewed: 2026-10-10 · Last updated: 2026-10-13 · Change: minor (zoom and pan regenerate in the background) · Target: Autodesk AutoCAD 2027 (Mac and Windows)
The hardware AutoCAD uses and how CADCraft compares, per platform. Work items: gaps.md.
Headline (estimated): hardware ≈ 45%. 2D GPU drawing, HiDPI and trackpads are covered on every platform. Missing: 3D mice, tablets/digitizers, GPU-accelerated 3D (there is no 3D), and any deliberate multi-monitor handling. Remaining: ≈ 15–25 Opus 5.5 hours, plus a human with the devices to test 3D mice and tablets.
Measured from the source on 2026-10-10 (crates/ui-egui/src/gpu.rs, canvas.rs,
apps/cadcraft/src/graphics.rs, apps/cadcraft-web); AutoCAD's side from Autodesk's system
requirements and graphics-performance documentation. Nothing was benchmarked in this pass.
| Feature | AutoCAD 2027 | CADCraft macOS | CADCraft Windows | CADCraft Linux / FreeBSD | CADCraft web |
|---|---|---|---|---|---|
| GPU canvas for 2D | yes (hardware acceleration, GPU smoothing, high-quality geometry) | wgpu on Metal | wgpu on DirectX 12 by default (WGPU_BACKEND overrides; GL avoided after AMD crashes, #31) |
wgpu on Vulkan (or GL) | WebGPU, WebGL2 fallback |
| CPU fallback | software mode | yes (tiny-skia rasteriser) |
yes | yes | — |
| GPU for 3D (shaded visual styles, ray-traced rendering) | yes | no (no 3D) | no | no | no |
| Low-latency presentation | yes | vsync or low-latency via CADCRAFT_VSYNC |
same | no vsync queue so the crosshair keeps up (#183) | browser-controlled |
| HiDPI / Retina, display scaling | yes | yes (egui points per pixel) | yes; a Windows 11 DPI fix is queued upstream (PR #110) | yes | yes |
| Multi-monitor (palettes on other screens, per-monitor DPI) | yes | not handled deliberately; one window | same | same | — |
| Trackpad pan, pinch zoom | yes (Mac) | yes, with trackpad vs wheel detection (#58) | wheel only (precision touchpad untested) | wheel; delay reported on Linux Mint (#25) | browser events |
| Magic Mouse | yes | treated as a trackpad | — | — | — |
| Wheel mouse, middle-button pan | yes | yes | yes | yes | yes |
| 3D mouse (3Dconnexion SpaceMouse) | yes | no | no | no | no |
| Pen tablet / digitizer (TABLET command, calibration) | yes (Windows) | no | no | no | no |
| Screen magnifier following the cursor | yes | — | breaks (#39; PR #187 adds a system-cursor option) | — | — |
| Plotters and printers (PC3 devices, system printers) | yes | no: PDF/PNG/SVG files only; Print asks where to save the PDF (#26) | same | same | PDF bytes shown instead of a download (#134) |
Performance on hardware (internal numbers only)
From the earlier roadmap (measured by the agents that built it, 2026-10-06, cadcraft-cli perf):
200,000 entities pick in 0.001 ms, about 4 ms after an edit (incremental R-tree), and the GPU
canvas draws a frame in about 4 ms. Nothing has been compared with AutoCAD on the same machine,
and 1M-entity drawings are untested. A 10 MB DWG took about two minutes to fail (#57).
Zoom and pan no longer freeze the window (2026-10-13). On a hatched 12k-entity architect's DWG (about 340k display primitives) each zoom step used to block the UI for 2–4.5 s while the display list, its vertex data and its GPU buffers were rebuilt. These rebuilds now run on a worker thread while the previous list is drawn, so the longest stall is 26–64 ms (M-series Mac). Edits still rebuild on the UI thread (about 1.8 s on that drawing): per-entity caching is the next step.
Revision history
| Date | Change | Summary |
|---|---|---|
| 2026-10-13 | minor | Zoom and pan regenerate in the background: 2–4.5 s stalls down to 26–64 ms on a hatched DWG |
| 2026-10-10 | major | First hardware parity doc: GPU backends per platform, input devices, displays, plotters |