Help users diagnose notebook rendering problems

[mjbvz]

Problem

It is currently difficult for users to tell if notebook rendering issues are caused by VS Code or by an extension. The issue here may be incorrect rendering or it may be a performance issue related to rendering. If the issue is caused by an extension, we want this to be very clear to the user so that they report the issue in the proper place and can also work around it

A few examples of how rendering can cause issues for users:

• The user has selected the incorrect renderer for a given cell/output

• A contributed renderer has a rendering bug

  Note that one bad renderer may also break unrelated cells in the notebook. For example, a renderer that contributes global css may end up styling all cells in the notebook, not just the cells/outputs it renders

• A contributed renderer is taking too long to load (would slow down initial rendering of the notebook)

• A contributed renderer is taking too long to render (would cause performance issues every time a cell is rendered)

• Any of the above three issues, except for a contributed render that extends one of our built-in renderers instead

• A renderer does something lazily, triggering the notebook cell be resized and potentially shift around our notebook content.

At present, users don't have many tools to help track down any of these problems.

Other interesting related perceived performance issues:

• The kernel is slow

• Exchanging messages between various processes (kernel, extension host, renderer, webview) is slow

Goal

Provide users with the information and tools they need to investigate and resolve rendering issues. Using these tools, users would be able to track down a misbehaving extension and disable it to work around any issues.

Exactly what these tools will look like needs further discussion

[rebornix]

@mjbvz thanks for putting this all together and the issue list @phgmacedo curated in #147253 (comment) aligns with the categories above ❤️

In addition to rendering issues affected by renderers, there are a few other things that go wrong and affect the perceived experience (slowness)

• File opening
  • Starving extension host slow down serialization/deserialization (allow users to run notebook extensions in dedicated extension as a fix)
  • Initial webview load and markdown preview warmup
• Bandwidth and latency between UI and extension host (remote eh, i.e. Jupyter over remote ssh sometimes becomes slow and/or unresponsive #138784)

We currently only have a perf mark for file opening perf analysis, maybe we could extend it to a command which enables perf troubleshooting and print logs to a dedicated output channel (similar to Keybinding Troubleshoot).