Feature : major : Crash after trying to view large media set

I have been stress testing Scrivener lately. I have a group with 460 image files in it, and the application is set to show images in Polaroidsâ„¢. Naturally, it takes a while to parse this into pretty little cards. In fact, I am not sure how long it even takes as I’ve never actually seen it finish. If you select another item in the Binder with the Corkboard still active, the application will crash a second or two later.

Added condition: While keeping the selection in Binder, pressed Cmd-1 to switch to Outliner. Outliner produced a list of the 460 image files. When I pressed Cmd-2 to switch back to Corkboard, it crashed. So it might be related to a threading issue? Two Corkboard threads trying to operate at once? If that is the case, a termination of the thread on view change might be all that is needed.

As an aside, so far Scrivener is handling a large file very well! I currently have it loaded with 150,000 words, and around 500 media files. The project size is 20MB. It loads instantaneously; does not exhibit any auto-save lag; takes seconds to globally replace “the” with “abracadabra”; instantly composites a 140,000 word E.S. session; and only takes around 7 seconds to export the draft. Um, impressive, to say the least, especially considering that it is a file based application, and not a database application like VoodooPad and Mori. Memory footprint is very conservative at this scale, too.

Thanks. I’ve put this on the list of things to do when I go through the corkboard code, which is the main bulk of the work I need to do before releasing beta 2. I thought the Polaroids cause some problems, as creating all of those images can be very slow. At the moment, it’s not using a separate thread to do this, so I might actually need to do so.

As for speed - yes, it should be pretty nippy. I did a lot of tests on this, and through the various incarnations of Scrivener I’ve been trying to optimise as much as possible. I tested E.S. with 360,000 words built from around 50 documents and it had no slowdown. It did slow down with about 1,000,000 words built from 1,000 documents, but then if anyone is going to write that much they need to be slowed down. :slight_smile: One of the reasons it can be fairly quick is that auto-saves only ever save documents marked as needing a save (usually only one or two) and the binder information. Anyway, it is mostly holding up in tests.

Like I say, I’ll get onto the crash. Do you have a crash log?

Oh yes. I even made one and uploaded it, but forgot to link it, here it is.

Excellent! Thank you, that narrows things down very helpfully - the crash is in a method I added only recently that is supposed to speed things up by caching images for the current contents. Will look into it.

Well, I’ve speeded up the corkboard view quite a lot. I have improved the code so that it only loads the images that are actually visible. So if you have 200 images, only about 9 will ever be loaded at any one time. This keeps things fairly nippy. (Actually, this was supposed to be how it worked before, but I hadn’t optimised it properly.) Also, there was a bug where it would crash if you tried to import some image files when lots of other image files were visible in the corkboard. This one pretty much hung the system. Hopefully this is fixed too. There’s still a fair whack to do to the corkboard, though.

For instance, if you can narrow down the circumstances in which the drop bars are drawn too long, I would be very grateful - I still haven’t got to the bottom of that one.

I have been trying to get that one, but I have yet to even see it, let alone find a path for making it happen.