Avoid Framebuffer view clears/redraws when moving between drawcalls
- Dominant language
- Go
- Stars
- 1.1k
- Forks
- 169
- PR merge metrics
- No merged PRs in 30d
Description
AGI TOT as of commit [43f58e352c](https://github.com/google/agi/commit/43f58e352c10968c4478f4e3c27e3688f03742fa), 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.
Contributor guide
Assessment
This issue has not been assessed yet.