Performance targets Coming
ComingThis feature is designed but not in DimSum yet. This page describes how it will work.
The speed DimSum promises: how fast it starts, opens, pans, recalculates and saves, and what you should expect on big plan sets.
Overview
- slow rendering and lag on large plan sets,
- joist and beam labels that take forever to generate,
- slow switching to the report tab while the report "generates",
- bulk property changes on the Estimating tab that only show up after a restart.
DimSum sets hard performance budgets for every release and checks them automatically. Labels, reports and quantities are updated incrementally in the background, so there's never a blocking "generating…" wait.
This page translates those budgets into what you'll experience at your desk.
Where to find it
There's no performance screen to operate. Related controls:
- Settings → Performance: GPU on/off, tile cache memory, background rendering threads.
- Settings → Storage & Files: cache size and the Clear Cache button.
How to use it
You don't have to do anything to get this speed. To keep DimSum at its fastest:
- Import vector PDFs whenever you can. They stay sharp at any zoom and support snapping and line extraction. Scans are fine but limited by their resolution.
- Scan paper plans at 300–400 DPI if you must scan. Lower resolution looks blurry when zoomed in; much higher just makes bigger files.
- Leave the GPU on (Settings → Performance) unless you're troubleshooting.
- Give the cache room. A bigger cache means less re-rendering when you jump between pages you've already viewed.
- Keep working while big imports run. A 200-page PDF becomes usable within seconds; the rest converts in the background with a progress bar.
Options & settings
| Setting | Where | What it does | Default |
|---|---|---|---|
| GPU on/off | Settings → Performance | Hardware-accelerated canvas and 3D | Not specified in plan |
| Tile cache memory | Settings → Performance | Memory reserved for rendered tiles | Not specified in plan |
| Background rendering threads | Settings → Performance | Threads used to pre-render tiles around your view | Not specified in plan |
| Cache size / Clear | Settings → Storage & Files | Disk space for tiles and 3D meshes | Size-limited |
Examples
What you should expect
| When you… | You should see | Budget |
|---|---|---|
| Launch DimSum | The app ready to use | Under 2 s (cold start) |
| Open a project | The first page visible | Under 1 s |
Open a very large project (500 MB .dsum) | The first page visible | Under 2 s (plan chunks load lazily) |
| Import a 200-page PDF | The first page usable; thumbnails fill in as they're ready | First page under 2 s, rest in the background |
| Switch pages | The new page on screen | Under 150 ms |
| Pan and zoom | Smooth motion with no blank patches | 60 fps; no blank tiles after 250 ms |
| Go back to a page you've already opened | Nothing to wait for | No visible loading at all (pre-rendered, cached) |
| Put a lot of takeoff on one page | No lag | 50,000+ shapes per page |
| Edit a value (e.g. wall height) | Every dependent quantity updated | Under 16 ms in a typical project (about one screen refresh) |
| Change a property on many tools at once (Estimating tab) | Every tool, label and total updated | Immediately; never needs a restart |
| Work normally | Your changes saved | Journal append under 10 ms, after every action |
| Change a joist spacing or an assembly slot | The joist layout / assembly regenerated, labels included | Under 50 ms for a typical floor area |
| Switch to the Reports tab | The report already up to date | Instant (reports recalculate in the background) |
| Preview a 500-row report | The preview rendered | Under 1 s |
| Orbit the 3D view | Smooth motion | 60 fps with 10,000+ tools/shapes visible |
| Edit something in 2D with 3D open | 3D updated | Under 16 ms (only the affected mesh rebuilds) |
| Open the 3D view of a full project | The model on screen | Under 1 s |
| (Later, cloud) Sync a typical edit | The change on your other machine | Under 2 s end-to-end |
Why we render the PDF instead of converting it
Both approaches pay the same bill in different places:
| other takeoff software | DimSum | |
|---|---|---|
| Import | Rasterises the whole set to TIFF — minutes | Near-instant |
| Panning | Nothing left to compute | Renders tiles as you go |
| Sharpness | Crisp at the TIFF's DPI, and can't get sharper past it | True vector — re-sharpens at any zoom |
| Colour | Flattened at conversion | The plan as the architect drew it |
We keep on-demand rendering: the import wait is real time out of an estimator's day, and losing zoom sharpness is losing the thing that makes a detail readable. But the panning cost is ours to remove, in this order:
- An instant low-res backdrop. One small whole-page texture per page, always resident, drawn under the tiles. You'd never see blank canvas — only briefly soft. Most of what "no loading" feels like is simply never seeing a hole.
- A cache that survives the session, keyed by page content hash, so the second time you open a job it's already warm.
Measured every run.
Real scenarios
- Big multi-family set. You import a 300-sheet PDF for an apartment complex. Within about 2 seconds the first sheet is on screen and you can start reordering and renaming pages while thumbnails keep appearing.
- Dense framing page. A floor with several 2x10 joist areas generates thousands of members with labels. Panning stays at 60 fps, and changing 16" O.C. to 12" O.C. regenerates the layout and its labels almost instantly.
- Deep zoom on a detail. You zoom to 10,000% on a vector PDF to read a tiny note. The lines stay razor sharp because the tiles re-render from the vectors.
The measured numbers
| Measure | Budget | Measured |
|---|---|---|
| Page switch, first visit | < 150 ms | 35 ms and 106 ms |
| Page switch, revisited | no visible loading | 1 ms and 2 ms |
| Pan frame, median | < 16.7 ms (60 fps) | 7.0 ms both runs |
| Pan frame, p95 | < 16.7 ms | 7.3 ms and 7.4 ms |
| Blank tiles during the pan | 0 | 0 both runs |
| Sharp tiles at the end of a hard pan | 11 of 15, then 6 of 15 — the rest are backdrop, i.e. soft |
Both numbers, not the better one. A cold page switch varies with what the pre-render pass has reached; 106 ms is still inside the budget and is the more honest one to plan against. The pan numbers barely move, which is the point: panning is the thing you do all day.
p95 rather than the median, because a stutter is what you feel; a good average with a bad tail is a bad experience. Blank tiles are pass/fail: the rule is "Never blank — soft is fine, blank is not", so a stretched backdrop counts as drawn and a hole does not.
The caveat that matters. This is an almost empty page. Until then these numbers prove the tile pipeline, not the whole picture.
Tips & shortcuts
- Page through with
PgDn/PgUpand levels withCtrl+PgDn/Ctrl+PgUp; page switches are designed to be near-instant. - Hide tool types you're not working on (View tab) to reduce visual clutter on dense pages.
- If a raster scan looks soft when zoomed in, that's the scan's resolution limit, not a rendering problem.
Rules, limits & edge cases
- Raster detail is limited by scan resolution. Beyond it, pixels are smoothed/magnified.
- "Typical project" and "typical floor area" are the benchmark baselines; very large or unusual projects may take longer on recalculation and regeneration.
- Budgets assume the GPU is enabled.
- The sync budget applies only to the later cloud service; v1 is local.
- During the build, speed is measured on the Windows machine; macOS/Linux numbers are verified before the commercial release.
Related features
- Architecture overview
- How DimSum is built (build process)
- File types & the .dsum project file
- Plan import & auto-conversion
- 3D viewport
- Joist & Rafter tools
