Larger initial view size in disassembly view

[xisui-MSFT]

This PR fixes #129534

Changed from loading 100 instructions on init to 400 instructions.

[isidorn]

I see that there are other places that depend on the NUM_INSTRUCTIONS_TO_LOAD, for example the topElement element computation. Will this still work?

Wouldn't it make more sense that we just change the base constant, and not the multiplier just in one location?

@xisui-MSFT also please ping me on PR's that you create so I can respond faster :)

[xisui-MSFT]

This PR only changes the initial size of the view, and no other locations depend on the initial size of the view, since the size of the view is not fixed.

Since no matter how many instructions we load, it's unavoidable that the scroll bar will jump when one scrolls to somewhere near the top or the bottom of the list, I think the main reason the scroll bar looks jumpy is that, the proportion between the size of numbers of instructions to load and the number of the instructions is too large. For example, before the changes in this PR, the initial size of the table is 100, and number of instructions fetched every time is 50. So when one scroll the table to somewhere close to the top, the scroll bar jumps from the top to about 1/3 of the length. And now we load 400 instructions on init, the scroll bar jumps from top to about 1/9 of the length, effectively less jumpy.

If the number of instructions to load every time is changed (by changing the constant),the proportion doesn't change, and so the scroll bar will be just as much as before, although it jumps less. But I think by only making the initial size of the table large, the interest of scrolling beyond the initial size is significantly reduced, because it's usually much easier to go to an instruction address via stack frame or current instruction than browsing through several hundreds of lines of disassembly.

No other locations depend on the initial size of the view, since the size of the view is not fixed. So all calculations for index or position are relative. Since you mentioned the calculation for topElement specifically, let me explain it here. The index of the current first element in the viewport is Math.floor(e.scrollTop / this.fontInfo.lineHeight). We are scrolling up in this case, so use Math.floor is unnoticeable. When load instructions at the top, the index of all the instructions changes, but the index being shown wouldn't change, making the view jump. So we calculate the index of the first element in the view after loading instructions by adding the index of the first element in the view to the number of instructions to load, and reveal this index after the actual loading action. This way the scroll bar jumps, and the view itself would not jump.

[isidorn]

@xisui-MSFT thanks for the clarification, it makes sense. Merging this in.