Allow custom binary editors to opt out of auto save

[Tyriar]

I've discovered Luna Paint has some issues with auto save, I've fixed some of the problems that can be seen in the existing stable release like reloading and losing history when a save occurs and preventing operations from finishing when auto save is enabled (which doesn't feel great), but some I don't see a way forward on.

1. Large images take time to encode - Partially coming back to common perf issues I hit again (Support web workers in webviews #87282, slow data transfer), large images take time to encode so we don't want to keep trying to save it as it will drain too much cpu/battery.
2. Encoding is important - I'm planning on eventually having a modal that will show during a save to select encoding options (quality, interlacing, etc.). While I may be able to infer these from what was used the previous time, I won't be able to do that all the time. Saving an image with the wrong encoding could cause unexpected data loss.
3. Saving often causes mutations to the image - When saving an image with multiple layers as a png the image should be flattened. I can work around this by exporting a flattened version and not actually flattening, I think the expectation here is that auto save would be disabled for cases like this where the image is incompatible with the last saved format.

I tried to workaround this by suggesting in the readme to do something like this:

"file.associations": {
  "*.png": "image"
},
"[image]": {
  "files.autoSave": "off"
}

But that has several problems:

• [*.png] isn't supported to target extensions only
• I cannot create a new language type like this
• I cannot disable auto save per file

My proposal is to allow throwing or rejecting somehow during CustomEditorProvider.saveCustomDocument and to add an indicator on whether this was an autosave so I know which ones to respect and which to reject. That way I can support auto save for small images and/or when the image encoding is lossless, I can stop respecting auto save just like I do with hot exit.

export interface CustomEditorProvider {
  /**
   * If the custom editor is unable to respect an auto save, throwing will mark the editor as dirty (without notification).
   */
  saveCustomDocument(document: T, cancellation: CancellationToken, isAutoSave: boolean): Thenable<void>;
}

It would be ideal if auto save continued to try as well, that way for example I could reject an auto save when a "Draw Rectangle/Line", etc. action is made which doesn't commit any pixels to the image yet, and resolve the save when "Finish Rectangle/Line" happens.

[bpasero]

Throughout our custom editor discussions we explicitly wanted all custom editors to behave exactly like normal editors and that includes support for auto save as well as hot-exit.

If the custom editor is not performant saving every one second, then maybe it could buffer the requests and simply delay the save to every 2s or even 5s?

[Tyriar]

@bpasero images could take much longer than 5 seconds to save depending on the size, right now this is not an option because worker support is not there which means a save locks up the tab. You can see the webview freeze happening on a relatively small image below due to a hot exit backup:

Getting web worker support in webviews (#87282), postMessage to support transferables (#115411) and control over context loss (#113705) would go a long way in making this nicer (and fixing the hot exit issue completely), but it still wouldn't fix points 2 and 3 above which are about data loss when saving an image.

Some examples:

• Open a png and create a layer, that layer cannot be saved since png doesn't support layers. It could be flattened and then saved but that would result in data loss.
• Open a jpg and make any change, each time the image is saved it will get recompressed, likely lowering the quality of the image each time.

[Tyriar]

I have a workaround now that warns people. From release notes:

Would be better to not need to do this though. Please close if it's not going to happen since I see @bpasero gave it a 👎

[vscodenpa]

We closed this issue because we don't plan to address it in the foreseeable future. If you disagree and feel that this issue is crucial: we are happy to listen and to reconsider.

If you wonder what we are up to, please see our roadmap and issue reporting guidelines.

Thanks for your understanding, and happy coding!