DevTools/Planning/Performance/Details: Difference between revisions

===Product Design Challenges===  

Memory and frame rates go hand in hand - the former can significantly impact the latter in memory-restricted environments. So this begs the question of how to integrate both memory and frame rare into a unified tool set that runs seamlessly. Here we lay out some design patterns that should be considered and incorporated into the whole design of the tools.  

'''1) Flame Charting'''<br>

In order to find problems, engineers need to be able to interact with their applications. It's not easy to go back into a recording and find problems if you forgot what you did when you recorded. So there is a need to provide live feedback, allow for a deeper dive, and, finally perhaps to pass over and record with deeper instrumentation. One possible concept is to allow for a combo live feedback and keep at least 15 seconds of recording in memory so that if the user sees a problem, he can hit a sort of "pause" button that would allow him to look at the last 15 seconds and see more details. Of course, this is not an issue while actually recording, but live feedback should always come with at least 5-15 seconds of "buffer" so that one can go back and look at what happened when say live frame rate feedback suggests a slow down.  

Does a developer really need to figure out whether to do a "timeline" or a "CPU profile" or a "whatever profile?". Isn't it enough to have one recording UI that provides a container for any "type" of recording? In reality, there is only one recording but with different depths of instrumentation. This does pose a challenge: how to have a combined temporal and memory based view. My gut tells me this is doable, we will just need to find an easy, user friendly way of doing it.

Design pattern 3) drives the need for being able to change the sampling/instrumentation depth. We have one recording, with multiple instrumentation depths possible.

A camera now days can take photos or videos. In this case, it's no different. We either record, or we can just take snapshots and compare. The user should still be able to be in the same UI.

Design pattern 5) drives the need for supporting snapshot bars, i.e. movable line along the time dimension that can allow one to do diffs across a recording and compare object counts, or, if snapshots are all that is available, the snapshots still show up as lines in a time dimension and can be selected to do diffs.   

While recording, it might be useful for engineers to be able to hit a shortcut key that will put a "mark" or a snapshot line into a recording to serve as bookmarks for example for a a before/after UI interaction bookmarking.