Real engineering schedules can be enormous — tens of thousands of activities, hundreds of thousands of dependencies. Most graph viewers grind to a halt around five thousand nodes. LogicReader is built specifically to stay interactive at the size of a real programme. This page sets the right expectations.
What we have tested at
- Up to 25,000 activities — pan, zoom, click all stay smooth on a modest laptop (8 GB RAM, integrated GPU).
- 50,000 activities — works, but with a noticeable couple-of-seconds pause on the first layout. Subsequent operations are smooth.
- Above 50,000 — stays usable with a discrete GPU. Below that, you may want to load by sub-programme rather than the full file.
How it stays fast: level-of-detail rendering
LogicReader switches rendering modes automatically as you zoom. Three bands:
- Close in (zoom > 50%) — full SVG: every activity name, every dependency arrow with arrowheads, every WBS group label. Looks like a network diagram should.
- Mid-range (15–50%) — simplified: activity names truncate, dependencies render as straight lines without arrowheads, WBS groups show a count.
- Wide view (< 15%) — WebGL marks: each activity is a coloured pixel cluster, dependencies are very thin lines, WBS groups dominate. The shape of the project is visible at a glance.
You don’t need to configure anything. The switch is automatic and reversible — zoom back in and the detail returns.
Tips for very large schedules
- Start with Fit, not by trying to navigate from a default zoom. Fit always works.
- Use Isolate aggressively. The whole programme is rarely the meeting topic.
- For comparison work, use Compare with both revisions; do not load them as separate sessions and try to flip between them — that loses the diff overlay.
- If your laptop is on battery and the schedule is huge, plug in. The WebGL renderer pulls more from the GPU than typical web pages.
If a schedule still feels heavy
Email us with the file (or a sanitised subset). We have spent significant time on the rendering pipeline and would rather hear “this one schedule is slow” than have you put up with it. Performance regressions are a high-priority bug class for us, not a “later” thing.