Inline values provider isn't called with new view port when scrolling editor content

[weinand]

from #105690 (comment)

DebugEditorContribution.updateInlineValueDecorations needs only be called when a provider is registered. The built-in fallback solution does not need to be called on scrolling because it does not try to only show inline values for the visible area.

[weinand]

@isidorn thanks, the fix works great.

Initially I thought that the viewport passed to the inline provider is a bit off, but then I noticed that I'm passing getVisibleRangesPlusViewportAboveBelow() which adds more lines above and below which is a good idea as my experiments show:

With getVisibleRanges() new lines appear without inline values and then after 200ms the values appear:

With getVisibleRangesPlusViewportAboveBelow() the inline values scroll smoothly into the view because they were already added in the "PlusViewportAboveBelow" area:

Of course that only helps if scrolling stays within the "PlusViewportAboveBelow" area. For page wise scrolling it won't help.

[isidorn]

@weinand thanks for the gifs, they show the two strategies quite well.
Based on your comment I am adding verfied label.

[testforstephen]

One concern regarding dynamic viewport updates is that it may cause a large number of inline value requests while scrolling the editor. Considering that Java debugger does not support canceling requests, this may impose an additional performance cost on the debugger.

For most cases, the method where the stack frame is located should not be very long, and it's fast to return all results to VS Code directly. But with the latest approach, if I scroll the editor, it keeps triggering the InlineValuesProvider. this can lead to a lot of unnecessary repeated calculations.

I was wondering if we could introduce a mechanism to control whether or not the inline values need to be refreshed when the viewport changes. For example, allow the InlineValuesProvider to return an "incomplete" flag. If "incomplete" is false, then there is no need to ask for inlineValues again on scroll. but if true, then re-trigger the InlineValuesProvider on scroll.
The extension can decide whether to return full results or partial results depending on the length of the source code.

[isidorn]

@testforstephen please note that we debounce this call. So we only call the provider only once the user stops scrolling.
I think in practice there will not be too many calls. Did you have a chance to try it out?

[testforstephen]

Yes, I tried it in Java debugger and debounce is taking effect. It's not the debounce I'm worried about, it's the fact that the inline values returned are volatile and not cached. As I scrolled up and down in the editor, new requests kept coming and I had to recalculate the same lines again.

Here is an example. In the very first window, the inline values in the stack frame are fully displayed, then scrolling down and back, the previous results are lost and I have to recalculate the results again. Ideally, it should be like lazy loading. I would prefer not to refresh the view again if the results have been provided before.

Screen.Recording.2021-04-08.at.15.50.56.mov

[weinand]

@testforstephen thanks for the details.
I've created #120803

[isidorn]

@testforstephen thanks this is helpful!
@weinand let me know if I can help with the issue once we decide to tackle it.