Composite Rectilinear Deformation for Stretch and Squish Navigation

Composite Rectilinear Deformation for Stretch and Squish Navigation James Slack, Tamara Munzner University of British Columbia November 1, 2006 Imager

Composite Rectilinear Deformation 4 Stretch and squish navigation • User selects any region to grow or shrink • Visual history of navigation • Simultaneous region resizing Growing a region 2

Successive Navigations Preserve History 4 Stretch and squish navigation composes deformations temporally • Navigation in regions affects entire view • Effects of all previous navigations persist 3

Is Stretch and Squish Navigation Hard? 4 Simple to use 4 Underlying infrastructure is complex to implement • Standard graphics pipeline has a single, monolithic transformation • Mathematical composition of multiple transformations • Stretch and squish cannot be implemented using this pipeline 4

Related Work 4 Stretch and squish navigation • Scales only to hundreds of objects • Rubber-sheet navigation (Sarkar 1992) • Document Lens, single region deformation (Robertson 1993) 4 General deformable surfaces • Scales only to thousands of objects • Non-linear magnification (Keahey 1997) • Pliable surfaces (Carpendale 1995) 4 Scalable visualization supporting millions of objects • No stretch and squish navigation techniques • Million. Vis (Fekete 2002) • Tulip (Auber 2003) 5

Related Work 4 Accordion Drawing Systems • Previous stretch and squish work focused on drawing • Assumed navigation algorithms existed, and never described • Tree. Juxtaposer (Munzner 2003) • Sequence. Juxtaposer (Slack 2004) • PRISAD (Slack 2005) 6

Contributions 4 Our contribution: an algorithm for stretch and squish navigation • Use PRISAD for drawing dataset objects • Scale to millions of dataset items • Not dataset-specific, a generic infrastructure for navigation • Visually composable • All previous actions visible • Deformations are lossless • Support for localized deformation 7

Complexity of Drawing 4 PRISAD rendering reduced the drawing complexity by culling • For each frame: draw representative visible subset, not entire dataset • (Total number of drawn objects per frame) << (Total dataset items) • In tree dataset with 600, 000 leaves, draw only 1000 leaves • In sequence datasets, aggregate dense regions in software 1000 leaves visible Dense, culled regions 8

Complexity of Navigation 4 PRISAD drawing complexity is in terms of visible objects • Draw objects at certain visible threshold 4 Navigation complexity determined by work done per animation frame 4 Navigation actions stretch and squish many objects simultaneously 4 Our algorithm update complexity is relative to regions that change • Number of regions to change simultaneously is limited • Grow just a few regions at once, dozens would be confusing! • Growing a region should not require updating every object • (Updates for navigation) << (Total dataset objects) 9

Grids and Regions 4 Stretch and squish a rectilinear grid, deform to navigate • PRISAD uses grid to render, layout, etc. • Normally not visible to end user 4 Atomic region: smallest navigation granularity 4 Composite region: collection of many atomic regions • User moves outer region boundaries, interior grid lines follow Atomic Region Composite Region 10

Grid = Pair of Line Sets 4 Separate horizontal and vertical line sets • Navigate simultaneously, independently in both sets 4 Use same navigation algorithm for both sets Vertical line set Horizontal line set 11

Moving in a Set of Lines 4 Navigation in a line set moves small number of lines 4 Suppose 1, 000 lines in horizontal line set 4 Only 1000 of these lines are used by PRISAD for drawing given frame • Visible regions between pairs of lines large enough to draw 4 Move small number of lines marked in red to new locations • Boundaries of composite regions • Not necessarily a subset of visible region boundaries 12

Usage Scenario: Expand 3 Regions 4 3 composite regions marked by user to grow vertically • 3 vertical regions to grow = 6 line boundaries to move • No horizontal navigation in this example Grow 3 regions vertically 13

Moving Lines 4 A navigation may change many grid line positions 4 Every grid line potentially moves in a single navigation 4 Updating every grid line would be too expensive • To avoid linear update cost, we introduce a hierarchy 14

Split Line Hierarchy Subdivision 4 We build a balanced binary hierarchy from each line set • Called split line hierarchy, also used for PRISAD rendering Entire horizontal line set Smaller example Entire horizontal line set Central line Children of central line Deeper regions of hierarchy 15

Split Lines 4 Split lines order grid lines hierarchically • Split lines are positioned between 2 split lines in the hierarchy • Central split line bounded by scene boundaries • Split lines are bounded by parents • E. g. C is bounded by B and D 16

Split Line Position versus Ratio 4 Each split line has an on-screen position 0. 0 0. 3 0. 5 0. 7 1. 0 4 We store ratios for each split line • Ratio is relative distance of a split line between its bounds 0. 5 0. 6 0. 0 0. 3 0. 5 Positions 0. 4 Ratios 0. 7 1. 0 17

From Ratio to Position 4 Ratios store positions indirectly with respect to ancestor positions • Position = (left bound) + (ratio) x (right bound – left bound) • 0. 7 = 0. 5 + 0. 4 x (1. 0 – 0. 5) 4 Positions can be computed in logarithmic time: ancestors in hierarchy • Positions computed only on demand, not for all objects • We may cache positions during one animation frame 0. 5 0. 6 0. 0 0. 3 0. 5 Positions 0. 4 Ratios 0. 7 1. 0 18

Navigation Algorithm Complexity 4 Input: set K of split lines with final positions • Only identity and positions of red lines required for input 4 Output: set Q of split lines with final ratios • Algorithm determines which additional lines require a new ratio • Changing ratios of these lines to output values will move K split lines • All relative positions between red lines are preserved 19

Running Example of a Navigation 4 Total number of split lines: 1023 4 Selected split lines to move: 4 4 Input to algorithm: K (indices) position 63 191 255 639 0. 3 0. 4 0. 6 0. 9 final position 0. 2 0. 5 0. 6 0. 7 ratio 20

Navigation Algorithm 4 Flow of our navigation algorithm: move. Split. Lines Initialize resize Recurse partition interpolate get. Ratio 21

Algorithm: move. Split. Lines Initialize 4 Initialize split line set that user wishes to move • M = split line list: input from user, plus left and right bounds • S = split line for partition: root split line (index 511), exact middle • Q = output ratios list: { } M (indices) 0 63 191 255 639 1022 position 0. 0 0. 3 0. 4 0. 6 0. 9 1. 0 final position 0. 0 0. 2 0. 5 0. 6 0. 7 1. 0 ratio 22

Navigation Algorithm: resize move. Split. Lines Initialize resize Recurse partition interpolate get. Ratio 23

Navigation Algorithm: partition move. Split. Lines Initialize resize Recurse partition interpolate get. Ratio 24

Algorithm: partition 4 Partitions set M according to location of S 4 S = 511, between 255 and 639 S = 511 M (indices) position 0 63 191 255 639 1023 0. 0 0. 3 0. 4 0. 6 0. 9 1. 0 final position 0. 0 0. 2 0. 5 0. 6 0. 7 1. 0 ratio 25

Algorithm: partition output 4 Partition returns L and R: S index initial position (i) final position (f) ratio 0 0. 0 63 191 255 511 0. 3 0. 4 0. 6 0. 7 0. 2 0. 5 0. 6 ? Left (L) S 511 639 1023 0. 7 0. 9 1. 0 ? 0. 7 1. 0 Right (R) 26

Navigation Algorithm: interpolate move. Split. Lines Initialize resize Recurse partition interpolate get. Ratio 27

Algorithm: interpolate 4 Interpolate determines the final position of S (index 511) • Since S must be between 255 and 639 with same ratio: • f[S] = f[left] + (f[right] – f[left]) * (i[S] – i[left]) / (i[right] – i[left]) = f[255] + (f[639] – f[255]) * (i[511] – i[255]) / (i[639] – i[255]) = 0. 6 + (0. 7 – 0. 6) * (0. 7 – 0. 6) / (0. 9 – 0. 6) = 0. 63 S index position (i) final position (f) ratio 0 0. 0 63 191 255 511 0. 3 0. 4 0. 6 0. 7 0. 2 0. 5 0. 63 ? Left S 511 639 1023 0. 7 0. 9 1. 0 0. 63 ? 0. 7 1. 0 Right 28

Navigation Algorithm: get. Ratio move. Split. Lines Initialize resize Recurse partition interpolate get. Ratio 29

Algorithm: get. Ratio 4 Finally, compute ratio for S with new final position for S • Ratio S = Final 0 + (Final 511 – Final 0) / (Final 1023 – Final 0) = 0. 0 + (0. 63 – 0. 0) / (1. 0 – 0. 0) = 0. 63 • Add S to Q S S index Position (I) final position (F) ratio 0 0. 0 56 73 0. 4 0. 2 0. 5 Left Q: index ratio 300 511 0. 6 0. 7 0. 63 511 754 1023 0. 7 0. 9 1. 0 0. 63 0. 7 1. 0 0. 63 Right 511 0. 63 30

Navigation Algorithm move. Split. Lines Initialize resize Recurse partition interpolate get. Ratio 31

Recursion 4 Each recursion step computes one split line ratio Q: index ratio 511 255 127 63 191 767 639 0. 63 0. 95 0. 43 0. 77 0. 71 0. 59 0. 32 4 Algorithm termination: when a partition contains no more lines to move • When M=2, bounds of S have computed positions and ratios 511 639 0. 7 0. 9 final position 0. 63 0. 7 ratio 0. 63 0. 32 M (indices) position 32

Result: Algorithm Complexity 4 Logarithmic complexity: |Q| |K| log |N| << |N| • Q: Lines needing ratio updates • K: Lines to move • N: All lines 4 Many positions change, but few ratios require updates • Moving 2 grid lines only requires changing ratios for 8 split lines • Subtrees not affected will conserve their internal ratios 33

Results: Implementation 4 Speed: under 1 millisecond for |N| = 2, 000 lines 4 Generality: implemented in PRISAD infrastructure as proof of concept • Tree, sequence dataset visualizations 34

Results: Design Goals Met 4 Algorithm provides lightweight visual history 4 Algorithm supports localized deformations • Set final positions for local bounds to start positions Localizing boundaries 35

Future Work 4 Implement stretch and squish navigation in other architectures 4 Support non-rectilinear deformations • Localizing regions may assist in reducing complexity 36

Conclusions 4 First scalable algorithm for stretch and squish navigation • K log N performance to move K of N lines 4 Infrastructure for composite rectilinear navigations • Lightweight visual history • Move several region boundaries simultaneously • Localized deformation • Shown on trees and gene sequences 37

Acknowledgements Info. Vis group at UBC: Ciarán Llachlan Leavitt Dan Archambault Aaron Barsky Stephen Ingram Heidi Lam Peter Mc. Lachlan Melanie Tory 38

Download Software 4 http: //olduvai. sf. net/tj 39