Each brush stroke would need to store some image data for this to work.
No, brush strokes would be stored as paths that simply record the input information needed to reproduce what the artist did with her mouse or stylus.
I hear you about the issue of breaking changes though. I think it takes real discipline to develop a format that's adaptable and with the capability to let you migrate files without visible changes. It would take one hell of a test suite though.
Google Tilt Brush saves brush on strokes. It takes roughly a minute to open a moderately complex sketch sketch in that program.
The only way to not change the output is to match the the already released operators exactly. This is almost impossible unless you freeze the code for each operation after it has been released originally.
Well, what if your image editor used an interpreter and the nondestructive edits were recorded in the document as scripts which, when replayed, construct that layer of the image. That way you can change the application all you want as long as you don't break the interpreter.
As for Google Tilt Brush, well that's just a failure to use proper caching.
Proper caching brings us back to the question of memory usage that I started out with. For the record, I don't think that Tilt Brush can be accused of a failure to cache properly. It need to recreate sketched 3d models for VR and I thibk there is some kind of LOD stuff going on when creating the final geometry, based on the performance of the computer it is running on.
And yes, any descriptions of nondestructive edits is by its nature a script that needs to be replayed by an interpreter to get the final state of the document. No matter the level at which you introduce the interpreter, you cannot upgrade it without risk to backwards compatibility to existing documents.
And if you you want the script language to be low level enough so that the implementations of your operators need to be dumped into the document, then you need to (a) write about half of your program in said scripting language and (b) end up duplicating that in every dicument that is created.
Proper caching brings us back to the question of memory usage that I started out with. For the record, I don't think that Tilt Brush can be accused of a failure to cache properly. It need to recreate sketched 3d models for VR
Oh, so Tilt Brush is 3D? So it's not at all comparable to a 2D image editor. I don't see how proper caching of a fully nondestructive editor should use any more space than a Photoshop document with a ton of layers. In fact, I think it could use a lot less, since Photoshop wastes tons of space when you duplicate source images in order to build up filtered layers with masks and so on. A nondestructive editor could save the space by not duplicating those source images so much.
And if you you want the script language to be low level enough so that the implementations of your operators need to be dumped into the document, then you need to (a) write about half of your program in said scripting language and (b) end up duplicating that in every dicument that is created.
Yes, this is what I had intended. But I don't think it's as bad as you say. You don't need to dump the bytecode (or equivalent) of your entire editor into every document, you only need to include the bytecode needed to reconstruct each of the edits made by the artist.
The editor itself could even include the source code of all its operators and let the artist modify it as she goes. It would be like the Emacs of image editors!
Tilt Brush is comparable in that it has it need to work as ypu propose internally. And all it has to do is fill relatively small vertey buffers with geometry, yet it takes forever to load a file.
I am not going to create a full model to estimate memory usage and of the different designs. It is however clear that a nondestructive approach is more computationally heavy in principle because it will always rerun the same operations more often than a destructive one. And all these times do add up. An operation that takes 100ms after a click or keypress is perceived as practically instant. But 100 of these take 10 seconds. And there are operations in Photoshop that a lot longer than that.
What you say is all true, but I think it is still worth a try. There are a lot of optimizations that Photoshop simply doesn't do. Its ancient code base leaves a ton of room for improvement with a fresh start. I don't know who you get to build this thing though. Maybe I will one day.
How do you know that Photoshop could be a lot faster than it is right now? I would not dare to make such a statement unless I have seen its current codebase.
No, brush strokes would be stored as paths that simply record the input information needed to reproduce what the artist did with her mouse or stylus.
I hear you about the issue of breaking changes though. I think it takes real discipline to develop a format that's adaptable and with the capability to let you migrate files without visible changes. It would take one hell of a test suite though.