On 7 Sep 2012, at 21:35, Charles Srstka <cocoa...@charlessoft.com> wrote:
> On Sep 7, 2012, at 1:15 PM, Kyle Sluder <k...@ksluder.com> wrote: > >> I guess the question is, "why are you saving a 4GB file?" Media editors >> don't do that; they split the file into chunks and bundle them in a >> project folder. For other apps, we have document wrappers. > > Here's a contrived, but possible, scenario: suppose the user opens a 4 GB > file with a hex editor and adds one byte to the beginning of the file. The > whole rest of that file is going to have to be shifted over one byte to the > right, and the whole file's going to have to be rewritten for that. > > Here's something perhaps more likely: suppose you're editing something in a > compressed format, such that the only way to edit it is to decompress the > file, tweak it, and then recompress the whole thing. Even with something like > .zip, there's still the possibility that one of the individual files in the > archive may be large. > > For video files, suppose you have a consumer-level tool whose purpose isn't > to be a full-fledged authoring tool, but rather to do something quick and > dirty such as trimming the length of a video file (including moving the > beginning forward a bit), adding a soundtrack, converting formats, etc. Isn't > this kind of stuff what QuickTime Pro basically was? It, IIRC, directly > edited the video file, not a folder full of chunks (feel free to correct me > if I'm wrong). > >> If you really need to edit a single monolithic multi-GB file, there are >> ways to do it other than holding the entire thing in memory and >> overwriting the file on disk. For example, you can stream the file to >> disk as it's created and maintain a dirty list, or mmap the file and >> just let the VM system take care of it. > > It doesn't matter if the thing's in RAM, streamed, or mapped. If the whole > file has to be rewritten, that's going to take a while to complete no matter > where the data comes from. Yes, so consider your options here: When the user has explicit control over saving (the old model), then when they save, the UI has to come to a halt until that is finished with. Ideally your app reports its progress in some fashion other than the beach ball so users have a decent idea of when their save is completed. But if you bring together Lion's two new technologies for the document system — autosave-in-place and async saving — the problem is reduced. Under normal circumstances, the autosave can start quietly in the background without interrupting the user. The UI only need come to a halt if an action occurs which requires the document to have finished saving first. Some of the problem is that adopting async saving can be quite hard so many apps haven't yet, or do so poorly. _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
