diff options
| author | vadimt <vadimt@chromium.org> | 2015-01-12 16:41:04 -0800 |
|---|---|---|
| committer | Commit bot <commit-bot@chromium.org> | 2015-01-13 00:42:14 +0000 |
| commit | 151c8010c9c54ecd75bab276a3ac820763544da1 (patch) | |
| tree | b871c46ed5fab226101467ab477cbbcff88354ef /ui/wm | |
| parent | 4583e3ffb9904e72e5b4fd81dcf2bace32193ef1 (diff) | |
| download | chromium_src-151c8010c9c54ecd75bab276a3ac820763544da1.zip chromium_src-151c8010c9c54ecd75bab276a3ac820763544da1.tar.gz chromium_src-151c8010c9c54ecd75bab276a3ac820763544da1.tar.bz2 | |
Instrumenting windows message maps, and cleanup.
The latest findings showed that there is no jank in GetWindowUserData. I simply didn't instrument all descendants of WindowImpl. Knowing this, the jank is actually in ProcessWindowMessage implementations. They are implemented with message map macros, so I'm instrumenting all individual message handlers.
The other significant source of jank turned to be PeekMessage API calls. Since they synchronously deliver sent messages, I expect the actual jank to happen in ProcessWindowMessage methods for these messages, i.e. in the code I'm instrumenting now.
Note on performance: this CL adds up to 2 tracked object executions per message. At the same point, it removes instrumentations that report very little jank, some of them were executed per each message. So, we shouldn't worry about perf.
BUG=440919
Review URL: https://codereview.chromium.org/809253004
Cr-Commit-Position: refs/heads/master@{#311162}
Diffstat (limited to 'ui/wm')
0 files changed, 0 insertions, 0 deletions