Large sizes & speed (workarounds?)

I’m experiencing some trouble in canvasses with a lot of notes. The canvas I’m currently working in has 521 notes and probably a multiple in connections, and I would like it to be more.

It remains workable for very small notes, scrolling becomes a bit slower, but that’s to be expected with all the placements having to update. The lag with writing larger notes is less understandable however. It pretty much kills two processing cores ad infinitum. The first line is fine, but after that you can only write around 5-10 chars until my machine can’t cope anymore. At a certain point it simply becomes a requirement to split the the canvas up in two because of this.

I was wondering: is it the architecture of the program, or is there something I can do to speed things up? Besides splitting canvas, of course.

Yes, splitting up the canvas into topical sections is the best thing to do. Keep in mind you can drag a .scap file into another to create a link back to it, so the end result needn’t be terribly inconvenient.

I’ve hit 574 notes in one of my documents and it’s slowed down to the point of being unusable. Creating a new canvas isn’t really a viable - or desirable - workaround as everything on the page is interlinked and is being used to map out a cohesive concept.

Is such a drastic speed/performance issue to be expected at scale?

Yes, it is an expected limitation. Scapple’s design scope is toward simple, small files. It takes a different type of technology, and quite a bit more work to create something that can scale into the many hundreds of objects on a freeform canvas. The effective limiter will be your tolerance for increasingly sluggish response.

Sorry that’s probably not what you’d like to hear, but like I say it would require an entirely different sort of development effort (one not dependent upon the core drawing tools provided by the system) from the very start, and such would probably have resulted in a tool that is priced more in accordance with that increased effort.