2009/7/8 yahvuu <yahvuu@xxxxxxxxx>: > Nicolas Robidoux schrieb: >> At start-up, the user could be presented with a list of unfinalized >> workspaces, and asked whether to finalize each, or open each. > > just for clarification: by "workspaces" you're referring to nip2 workspaces, > which roughly translate to GIMP compositions, correct? For reference, here's how nip2 handles this: - the workspace (tree of operators) is saved to the temp directory every time you make a change (it keeps the most recent 10 I think) for undo and crash recovery - workspaces do not include thumbnails, it's almost always faster to recalculate them - import files (eg. when you load a PNG or SVG) are kept on disc in the temp directory and then mmaped for processing - image display windows have a small ram cache of recently-calculated tiles to speed scrolling and expose operations - there's a "cache" operator you can add to the graph explicitly if you wish, but no one uses it (it slows down calculation and increases memory use to some degree, and you are not guaranteed to win that invested time back again unless you start heavily editing certain parts of the composition, which you often don't) - if you use the paintbox (a very simple destructive image editor) on a node, it renders that node to a file in the temp directory at full resolution and you edit that image on disc via. a read-write mmap - paintbox undo/redo buffers are kept in ram - if you invalidate a node that's being painted, the associated disc file is deleted and rerendered - when you save an image, the fuil composition is rendered and not cached (they can be extremely large and there is again no guarantee that "spending" that disc space will produce a benefit) - if you save in a non-compressed format, you can always reload and save as JPG if you wish We have experimented with various caching or persistence schemes over the last 15 years or however long it is, but none of them have ever really stuck. Small, fast workspace files and not filling disc unexpectedly with large, speculative caches seem to be useful principles. On the other hand of course nip2 has few users due to it's hostile nature, heh. Anyway, it is one set of choices. John _______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
