Provide visibility-based rendering as part of the View API

[akhenry]

Is your feature request related to a problem? Please describe.

Throughout our code we make use of RequestAnimationFrame to ensure we are not trying to update the view any quicker than the browser can handle. Modern browsers will defer or throttle rendering of inactive tabs, however this does not apply to tabbed views within an Open MCT display, because of course the browser has no concept of Open MCT tabs.

To bring the benefits of optimized tab rendering to Open MCT tabbed displays we have implemented a class that defers rendering for elements that are not visible for any reason (including being scrolled out of view).

This visibilty-based rendering should be available via our View API so that third-party developers can make use of it as well.

Describe the solution you'd like
The Open MCT framework has a handle to a view's parent element and could use that to automatically observe for visibility. Open MCT could then pass an optional renderIfVisible function to the show function of views that would act like requestAnimationFrame except based on the visibility of the view's parent element. We'll also need to do

openmct/src/ui/preview/PreviewContainer.vue

Line 150 in 7f8262b

this.view.show(this.viewContainer, false, this.viewOptions);

Because Open MCT also knows when a view is destroyed, this would allow Open MCT to manage the entire lifecycle of the visibility observer and obviate any risk of memory leaks.

[scottbell]

@akhenry I've got a draft PR, but also have a question: should the PreviewContainer bother with visibility? I feel like in that case we should just fire requestAnimationFrame as needed as the object should certainly be visible. That's the implementation in the PR currently.

Otherwise, implementation was pretty straightforward!

Update: discussed above with @shefalijoshi and PreviewContainer is not bothering with visibility.

[scottbell]

To test:

1. Create a tabbed layout
   

2. Drop some high frequency data into one tab as stacked plots
   

3. Drop a large LAD table with high frequency data into another tab
   

4. Drop a notebook into another
   

5. Bring up the [performance monitor](https://developer.chrome.com/blog/new-in-devtools-64/) in Chrome.
   

6. Bring up the large LAD table and look at the performance monitor. Note the high CPU usage.
   

7. Bring up the plot and notice the high CPU usage.
   

8. Bring up the notebook, the CPU usage should decrease
   

[ozyx]

Verified Testathon 12/4/23

CPU usage drops when swapping tabs to the non-plot and non-LAD pages

[michaelrogers]

Fix verified on 12/04/2023.

CPU drop was observed when switching to a notebook from a high frequency plot or lad table tab.