Avoid Framebuffer view clears/redraws when moving between drawcalls

[mark-lunarg]

AGI TOT as of commit 43f58e352c, Host OS is Linux tracing on Google Pixel 5, Android 11.

This is a follow-on issue to #900. This issue was an enhancement request to preserve the previous Framebuffer image when moving between drawcalls to better discern the screen updates made in that drawcall. There are two behaviors which affected this:

• The attachment selection drop-down control has a thumbnail view of the selected FB image. This thumbnail was redrawn each time a draw call was selected causing the other controls in the panel, including the FB image, to move/flash. This was fixed by PR #911.

• When a new draw call is selected, the loading indicator is displayed until the target image is loaded. This results in a clearing of the framebuffer image, and if the image takes more than 0.5s to load, an animated loading indicator image is displayed in the center of the cleared area until the new image is available. Depending on the trace, the image may be blank for some number of seconds. If the selected image is already in cache, the FB image is cleared and the new image is displayed, causing a flash due to the clear. Occasionally, this can also take some portion of a second causing a noticeable flash.

To repo. capture at trace with multiple draw calls. Select a draw call in the Commands window, wait for it to be displayed, and then select a different draw call.

TODOs from @pmuetschard:

1. Figure out why it's so slow when the image is already cached and we don't need to do a replay.
2. Figure out what to do when we need a replay. Maybe overlay the loading indicator instead of clearing the image, or use a different loading indicator (like a spinning bar at the top/bottom), etc.

[mikes-lunarg]

This slowdown is most noticeable when the texture tab (~2000ms) and pipeline tab (~350ms) are open. When both of these tabs are closed the framebuffer view updates almost instantly. I can measure some additional time spent in the texture and pipeline views making requests and updating the UI, but a large chunk of the slowdown (~1500ms) is still unaccounted for. These times were measured flipping between 2 previously displayed commands, so all of the RPC requests should be cached and the server is not involved.