Open Radar

 
Summary:
Using Cocoa Layout, there is a lot of data but not much exposed for finding useful information to help debug.

Steps to Reproduce:
1. Profile app with Cocoa Layout Instrument.
2. Make changes in app that trigger layout changes.
3. Observe _no indication_ where end of recording trace is.
4. Observe visual trace is very light and hard to see.
5. Stop recording. Look at data.
6. Observe too many events that I don’t care about, but lack of obvious ways to filter.
7. Type “Constant Modified” (or another Event type from results) into search bar.
8. Type “H:” to get only horizontal constraint changes.
9. Observe that search bar for Event List -> Cocoa Layout does *not* resize or get wider, despite the large screen it is currently on. Also it is not possible to tab between the various search tokens / terms in the search field.
10. Observe that it is still difficult to narrow in on the right events, even with filtering the timeline (inspection range) on the instrument trace above.
11. Find the object of interest’s memory address.
12. Add that to the search filter. 
13. Observe that there is no context around that layout change - instead, you now *only* see events surrounding that.
14. Assume the layout also has a table or collection view, unrelated to what you are working on. Note that there are a lot of calls to them in the trace.
15. Attempt to remove calls involving those classes from the results via a negative search (“-MyItemCell”). Note this does not work.

Expected Results:
On step 3, should see a running line or other visual indication that trace is recording, and where the end of the trace is. This lets me space actions out by ~5 seconds (for example) so I can easily later inspect the various ranges. 
On 4, good contrast so I can actually see the data.
On 7, there are a known and small number of event types. Should be able to select that column and selectively add or remove certain events, to quickly filter to what I want there. Or there could be a toolbar or sidebar that makes it easier to move through those.
On 8, the Constraints table view column is very predictable. Ideally that column would get parsed and it would easy to select certain objects, or certain types of constraints. Even better, if there were some way to visually see what some objects corresponded to (similar to UI instrument) then instead of a memory address I could name certain objects.
On 9, *the search field should resize as wide as possible!*
On 10, smarter aided filtering/searching across all of the columns.
On 13, in addition to filtering the list below it would be nice to have a highlight mode, so I could see the matching rows but within context of the surrounding calls.
On 15, should be able to build a filter by removing things I don’t care about. Maybe I don’t care about “Constant Modified” events, or events on certain classes, or autoresizing mask constraints. 

Actual Results:
See Steps To R.

Regression:
Visual: the instrument trace is much harder to see.