Discuss upper bound for color decorations

[GlenCFL]

I have an extension for item filters, item-filter-code. Item filters are single file, with no concept of importing whatsoever. The most popular item filter is Neversink, which is nearing 5,000 lines. There are around 1,030 color decorations within this file.

The issue is that there seems to be a hard cap on the number of color decorations available within each editor. If you were to open Neversink with the extension installed, then the color decorations will cut off midway through the file. I believe that this is the line where the limit is set to 500.

I realize that this is likely done for performance reasons. My first thought was just to figure out which lines were visible within the editor and filter color decorations based on that; however, I don't believe this is currently possible with the current API, as I couldn't really find a way to determine the visible lines within an editor.

[jrieken]

We have proposed api for visible ranges of an editor (see https://github.com/Microsoft/vscode/blob/master/src/vs/vscode.proposed.d.ts#L642) but for validation purposes you really shouldn't use UI state but simply compute diagnostics and hand them over. You are right, the cap is done performance reasons because extensions could overload us. I wonder in what situations more than 500 diagnostics are actionable?

[GlenCFL]

On the original issue, I don't think the visible range API alone solves this problem. I don't believe there's a way to get Visual Studio Code to update the color decorations even if we are curating a collection of them within an extension. One solution to this might be Visual Studio Code itself calling into the provideDocumentColors callback, provided when registering a color provider, each time the editor stops scrolling. It only does this in version 1.24.0 whenever the document itself is loaded or edited.

Another option would be allowing color decorations to be created using TextEditor.setDecorations() by specifying a particular decorationType with the appropriate key as the first parameter. This might already be supported, but I couldn't find anything on it by searching this repository.

[jrieken]

@GlenCFL Yeah, we are discussion "semantic" highlights in this issue #51104. Do mind me closing this as dupe?

[GlenCFL]

@jrieken
Highlights would work so long as it does support color ranges, with the color picker and everything, so go ahead.

[jrieken]

For colors and to support the color picker we have DocumentColorProviders. With those, you can add color boxes and support the picker. Would that help you?

[GlenCFL]

That goes back to the original issue, where there is a hard cap of 500 decorations within each text editor. The provideDocumentColors callback that you provide when creating one of these providers isn't called whenever the user stops scrolling in the editor, so we cant update decorations appropriately.

[jrieken]

wow - yeah, this was a big mis-understanding... I figured this is about an upper-cap of diagnostics, not colors... Moving to @aeschli

[aeschli]

The limit (this is the line) is in the editor code.

[GlenCFL]

As an update to this, that item filter now has 1,300 color values, with the cutoff being about 43% into the file. I'd expect this number to increase to around 1,500 over the next six or so months.