What kind of interaction do we want here? Arrow keys for scrolling, +/- for zoom? Or implement a cursor/playhead that seeks across the graph?

I'm using W/S for zoom and A/D for plan left and right. W/S can also be used for panning and zooming can be left to the mouse well instead. To try it out: http://people.mozilla.org/~bgirard/cleopatra/#report=9673aa6606a57f0af73fae9404bec85f4743e4fa Hit 'Call Graph' in the middle-ish.

Is there a bug for making this mouse-accessible? Right now the only way to zoom in is the relatively coarse scroll / pan actions. It is common to expose vertical and horizontal slider UI to the user to a) indicate zooming is available and b) offer a more precise way to zoom.

No there's not, I believe -- do you mean scrollbars for pan/scroll (move left/right/up/down) or for zooming like a little scrubber on the side mapping to magnification (like Logic on OSX, can't find any images)?

No bug filed yet. What do you mean there's people not using trackpads? :) Yeah, should make it better.

How does this feel Jordan? Lemme know before I add any tests.

Hmm.. so this feels right, I'd say maybe the left/right speed could be a bit faster (or maybe accelerate). What's weird though is this is manipulating the selection, not the flame graph -- I'd assume I could also do this in other views, which I can't, and if we did apply them to there (as they're both abstract call tree views), they have their own keybindings, and we'd need a way to make sure they don't conflict (different key bindings? maybe have to give the details view or overview view focus?) Also, side note, how can we convey all these hotkeys?

More info in bug 1159044 as well

Rewrote this. (In reply to Jordan Santell [:jsantell] [@jsantell] (Please needinfo) from comment #10) > Hmm.. so this feels right, I'd say maybe the left/right speed could be a bit > faster (or maybe accelerate). Implemented acceleration for both zooming and panning. > > What's weird though is this is manipulating the selection, not the flame > graph -- I'd assume I could also do this in other views, which I can't The implementation does nothing to the "selection" as defined by the performance tool. In fact, the entire widget has no knowledge of the outside world. It's all contained inside the flame graph. > Also, side note, how can we convey all these hotkeys? Not sure, but I'd say that the arrow keys and WASD are pretty instinctual and don't need UI explaining them. You'd expect the DOWN/LEFT key to scroll in a document, same can be said in here.

Very slick. Code looks good, waiting for a build to finish to try this out

Comment on attachment 8715807 [details] [diff] [review] flame-key-access.patch Review of attachment 8715807 [details] [diff] [review]: ----------------------------------------------------------------- Really smooth and nice. Wonder if we could have this for other views too, like waterfall? Would it make more sense for this to live in the overview graphs, like the mouse controls for it do? And the details view will use their own implementation (row selection on calltree/waterfall), otherwise falling back to the overview graph control (flamegraph)? Either way, can be dealt with in a follow up. Smooth like butter.