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. >> Also, some file types are just large and complex, and take a certain >> amount of computing power to save no matter how "smart" you are. Have you >> ever tried opening and editing a really high-resolution image file with >> Pixelmator with autosave turned on? It gets almost unusable. With a video >> editor, it would be even worse. > > No I have not, but what I have done is used versions of OmniOutliner > that use old-school autosave on gigantic documents customers have sent > us (usually with huge collections of image attachments). Whenever the > autosave timer expires, the app freezes for ten seconds at a time > because it's doing a naive rewrite-the-world save. This isn't a product > of Lion autosave. I'm not a graphics guy, so I don't know if it's possible to do partial saves of, say, PNG files, although I'd be surprised if it could, given that the format is compressed. Sometimes you're stuck with a rewrite-the-world save, and in such cases any kind of autosave, whether it be Lion's kind or the old-fashioned kind, probably isn't what you want. >> Sure there are, and I gave you four of them (which doesn't necessarily >> rule out other cases that just aren't coming to mind at the moment). > > The reason I replied to your message is that I don't believe you > succeeded. You enumerated cases for which perhaps no good > *implementation* of Lion Autosave currently exists. But that does not > imply anything about the applicability of the *paradigm.* I dunno, I think they're decent examples of cases where you wouldn't want autosave at all (also with editing stuff on a remote server, you generally don't want that stuff pushed until it's ready). Charles _______________________________________________ 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
