Partitioned Rendering Infrastructure with Stable Accordion Navigation James Slack MSc Thesis...

Partitioned Rendering Infrastructure with Stable

Accordion Navigation

James SlackMSc Thesis Presentation

April 4, 2005

2

Overview

• Motivation & Background

• Related Work

• Generic Accordion Drawing– Accordion Drawing Infrastructure– Tree-specific Accordion Drawing– InfoVis 2003 Contest Entry– Evaluation of Generic Infrastructure

• Conclusions

3

Accordion Drawing

• Accordion Drawing is rubber-sheet navigation and guaranteed visibility of data

4

Accordion Drawing Navigation

• Rubber-sheet navigation metaphor– Borders tacked down– Stretch regions of interest

• Distortion of data in 2 dimensions– Dataset drawn on flexible surface– Data may be squished into small regions

• Regions may be less than size of pixel

– Data never pushed off-screen• All data maps to on-screen region

– Dense regions of data require culling

5

Guaranteed Visibility

• Guaranteed visibility marks are always visible– All marks are visible with small datasets

6

Guaranteed Visibility

• Guaranteed visibility is hard with big datasets– Naïve culling, on right, doesn’t draw all marked items

7

TreeJuxtaposer

• 1st Accordion Drawing application• Side-by-side tree comparison

[Munzner 2003]

8

TreeJuxtaposer

• Limitations– Scalability

• Maximum dataset size: 500,000 tree nodes• Slow rendering for large datasets

– Tree-specific Accordion Drawing• No separable infrastructure

Contributions

Generic Accordion Drawing (AD)

Trees on top of generic AD

InfoVis Contest

10

Generic Accordion Drawing

• New rendering infrastructure– Based on screen-space partitioning– Eliminates overculling

• Visually correct rendering

– Tightly bounds overdrawing• Pixel-based rendering constraints• Faster rendering of dense regions

• Numerically stable navigation– Support for multiple concurrent motions

11

Trees on Generic AD

• Tree topology traversing algorithms– Rendering and culling support– Layout of datasets

• Marking small regions of trees– Store continuous regions– Efficient traversal of marked regions

• Benchmarked with TreeJuxtaposer performance

12

InfoVis Contest

• Analysis of tree-specific AD– Incremental search with immediate visual

feedback– InfoVis 2003 contest dataset evaluation

Related Work

Other Tree Drawing Applications

Additional Dataset Domains

14

TJC

• Visualization of 15 million node binary tree– Grid-based, embedded AD infrastructure

• Top-down rendering– Subtree culling when subtree subtends 1 pixel

• Limitations– No support for multiple-tree comparison– Tuned for balanced binary trees– Tree-specific accordion drawing

• No separable infrastructure

[Beermann 2005]

15

Additional Domains

• Genomic Sequences– DNA sequence comparison– Aligned A,C,G,T data– Beyond scope of MSc thesis

[Slack 2004]

• Power sets– Set of all sets visualization– Built on my generic infrastructure– Submitted for publication

[Munzner 2005]

Discussion

Accordion Drawing InfrastructureTree-specific Accordion Drawing

InfoVis 2003 Contest EntryEvaluation of Generic Infrastructure

17

Application and AD Interplay

• AD requires application-specific algorithms– Bi-directional mapping (layout grid)– Applications conform to 3-step rendering pipeline

• Partitioning• Seeding• Drawing

• AD provides common algorithms for applications– Efficient rubber-sheet navigation– Infrastructure for partitioning– Render queue for drawing

Accordion Drawing Infrastructure

Split Line HierarchyRenderingNavigation

19

Bidirectional Mapping

• Map application-specific layout to 2D rectilinear grid• Define generic algorithms on grid• Reuse grid algorithms for all AD applications

– Navigation: stretching, squishing– Rendering: partitioning

20

Split Line Sets

• Two sets of split lines divide X & Y of a base grid– Size of sets determined by application

• X & Y line sets move independently

X 0 X 2 X 3X 1Y 0

Y 1

Y 2

Y 4

Y 3

21

Split Line Duality

• Split line interpretation duality– Split lines are an ordered list of lines

– Split lines are a hierarchical subdivision of space

0 1 2 3 4 5 6 7

421 3 5 6

22

Split Line Hierarchy

• Hierarchy forms regions– Binary subdivision of grid coordinate system– Each split line of hierarchy subdivides region

• Root split line is entire region for X or Y• Region restricts positions of all child regions

– Each region stores relative position of line• Use relative positions to calculate absolute split

line screen coordinates

23

Split Cell Root Region

• Center split line can move anywhere

24

Split Cell Child Region


• Left child of parent is bounded– Parent split line bounds all descendants

25




26




27

• Absolute positions depend on relative positions of all parents

• Hierarchy allows logarithmic region access

Split Line Hierarchy

29

Generic Partition-Based Rendering

• 3-step rendering pipeline– Partitioning– Seeding– Drawing

• Separate partitioning from drawing– Partitioning is hard: supported by infrastructure

• Constraints solve overdrawing, overculling problems

– Drawing is easy: application responsibility• Handle bite-sized pieces

• Seeding supports progressive rendering

30

Generic Partitioning

• Correct partitioning eliminates overculling

• Application partitions either horizontally or vertically– Trees partition topological leaves (vertically)

• Binary recursion in split line hierarchy– Stop when either

• Small enough segment of screen space– Application-specific termination criteria

• World-space item reached at hierarchy leaf

31

Generic Drawing and Picking

• Drawing and picking are application-specific– Depend on layout of dataset

• Use layout of dataset as representation of data relationships

• Drawing traversal follows partitioned ranges– Each partitioned range drawn independently– Application-specific minimal drawing for each range

• Traverse dataset topology to pick– Same traversal methods as drawing

• Any visible node is pickable and any pickable node is visible

32

Seeding Marked Ranges

• Marked items drawn first– Progressive guaranteed visibility

• Visual landmarks while navigating

• Application-specific seeding order– Usually, marks followed by partitioned ranges

34

TreeJuxtaposer Navigation

• Single lines move with subdivision hierarchy– Movement in O(log(n)), for n total split lines– Bottom-up traversal in hierarchy

• Moving k lines– Repeat k independent single line movements– Root split line moves k times

• Numerical instability

– Movement in O(k log(n))

35

Generic AD navigation

• Same complexity– Single line movement O(log(n))

• Top-down traversal, in total of n split lines

– k-line movement O(k log(n))

• Numerical stability for k-line movement– Any line moves at most once

• Two cases to consider– Single split line movement– Many split line movement

36

Single Line Navigation

• Move target split line to final position

• Recursion through split line hierarchy

• 4 properties of stable, efficient navigation– Target can be moved anywhere on screen– Split lines remain ordered during navigation– Each motion step moves ½ remaining lines– Final position of target calculated in first step,

guaranteed to move lines appropriately

37

Single Line Navigation

• An example navigation action:

• Hierarchy of split lines:

38

• Step 1: Move root of hierarchy

– Affects absolute positions of other split lines

Root Movement

39

Recursive Motion

• Each motion step moves ½ remaining lines– Right side of hierarchy finished after step 1– Recursion necessary only on left side

• Previous center becomes movement boundary

Left side

40

• Step 2: Move child center split line

– Affects absolute positions of other split lines• Only in its bounded region

Child Movement

41

Complete Movement

• Explained as recursive process

• Actually concurrent movements– Split lines move in own region

• All steps can run at same time

42

Many Line Navigation

• Grow several regions between pairs of split lines– Shrinking is inverse, grow the set of unselected regions– Each region grows in proportion of initial size– Regions between ranges preserve context

• Similar to single line movement– Top-down hierarchy traversal– Move relative line positions only

• Recursion on both halves of split line hierarchy– Stop recursion in empty range– Interpolate position of center line each step

43

Navigation Preserves Contexts

• Cannot squish regions to smaller than a threshold– Contexts preserved between and around regions in motion

44

Split Line Motion Interpolation

• Final position of blue center satisfies:Ileft ÷ (Ileft + Iright) = Fleft ÷ (Fleft + Fright)

Fleft Fright

I left I right

Discussion



46

Tree-specific Accordion Drawing

• Improved marked range storage– Seeding orders marked nodes before unmarked data

• Topology-based algorithms– Rendering traversal– Visible node picking

• Visible nodes can be picked, pickable nodes are visible

• Grid-based algorithms– Gridding (mapping tree nodes to grid)– Positioning edges during rendering

47

Tree Ascent Rendering

• Rendering with generic infrastructure– Partitioning

• Rendering requires sub-pixel segments• Partition split line Y, create leaf ranges

– Seeding• 1st: roots of marked sub-trees, marked nodes• 2nd: interaction box, remainder of leaf ranges

– Drawing• Ascent rendering from leaves to root

48

Tree Partitioning

1

2

3

4

5

• Divide leaf nodes by screen location– Partitioning follows split line hierarchy– Tree application provides stopping size criterion– Ranges [1,1]; [2,2]; [3,5] are partitions

L = [1,1]

L = [2,2]

L = [3,5]

0

1

2

49

Seeding Tree Nodes

• Marked subtrees not drawn completely in first frame– Draw “skeleton” of marks for each subtree for landmarks– Solves guaranteed visibility of small subtree in big dataset

50

Marked Ranges

• TreeJuxtaposer stores marks in linked list– Colors cached for every node– Retrieving color is expensive linear search

• 130 seconds to mark and redraw pair of 200k node trees• 1.5 seconds for cached drawing (marked or unmarked)

• Our infrastructure stores marked ranges in balanced trees– No caching required– Efficient ordering and range grouping

• 2.5 seconds to mark and redraw pair of 200k node trees• 0.3 seconds for unmarked drawing, 0.5 for marked

51

Gridding for Tree Drawing

• Mapping tree nodes to a base grid of split lines– Drawing depends on node mapping

52

Tree Gridding Process

• Tree properties determine base grid size– One cell in Y for each leaf– Enough cells in X for height of tree

• Nodes placed in grid in post-order– Bounded by split lines– Parents span their children– All siblings connected to parents

53

Tree Gridding Example

• Each node assigned rectangular region– As wide as sum of children widths– Tall enough to reach parent

• Siblings all at same height

56

Tree Drawing Traversal

• Ascent-based drawing– Partition into leaf ranges before drawing

• TreeJuxtaposer partitions during drawing

– Start from 1 leaf per range, draw path to root– Carefully choose starting leaf

• 3 categories of misleading gaps eliminated– Leaf-range gaps– Horizontal tree edge gaps– Ascent path gaps

57

Tree Ascent Drawing

• Use seed queue to draw nodes

• Determine minimal set to draw– Use tree topology, select best nodes

1

2

3

4

5

L = [1,1]

L = [2,2]

L = [3,5]

0

1

2

58

Leaf-range Gaps

• Number of nodes rendered depends on number of partitioned leaf ranges– Maximize leaf range size to reduce rendering– Too much reduction results in gaps

59

Eliminating Leaf-range Gaps

• Eliminate by rendering more leaves– Partition into smaller leaf ranges

Discussion



61

InfoVis 2003 Contest

• Inaugural visualization contest at InfoVis 2003– Tree comparison contest– Several tasks on datasets– Judged by evaluation of methods used to solve tasks

• Using an information visualization tool• Tool created by either submitters or 3rd party

• We analyzed a modified TreeJuxtaposer– TreeJuxtaposer was well suited for tree comparisons– Our modifications focused on solving contest tasks

• TreeJuxtaposer lacked text entry for searching• User interface lacked feedback

62

Contest Dataset Evaluation

• 3 dataset types evaluated– Two 200,000 node classification trees– Four 90,000 node directory trees– Two 60 node phylogenetic trees

• Various tasks:– Generic tasks for all sets

• Individual tree visualization• Pair-wise tree comparison

– Specific tasks for each set• Attribute and specific characteristics of datasets

63

TreeJuxtaposer Contest Improvements

• Incremental search– Matching nodes highlight for immediate visual

feedback– Selectable list of search results

• User interface improvement– State of marking, selections visible– Graphical interface support of common

operations

64

Evaluation Results Overview

• Strengths of TreeJuxtaposer– Comparisons scalable to large datasets– Guaranteed visibility highlights small features– Rubber-sheet navigation provides smooth navigation

transitions• Limitations of TreeJuxtaposer

– Scalability restricted comparing largest datasets– Unable to analyze more than label attributes– No undo, editing, logging functionality

• Result of our contest entry:– Our analysis won first place overall!

Discussion



66

Evaluation of Generic Infrastructure

• Benchmark with TreeJuxtaposer performance– Comparison of InfoVis 2003 contest datasets

• Two 200k node animal classification datasets

– Comparison of OpenDirectory Project datasets• Two 500k node website categorization trees

– Synthetic dataset progressions, by powers of 2• Show “curves” through space of all trees • Up to 2 million nodes• Balanced binary trees• Star trees

67

Rendering Time Performance

• TreeJuxtaposer renders all nodes for star trees– Branching factor k leads to O(k) performance

• We achieve 5x rendering improvement with contest comparison dataset

• Constant time, after threshold, for large binary trees

68

Rendering Time Performance

• Constant time, after threshold, for large binary trees– We approach rendering limit of screen-space

• Contest and OpenDirectory comparison render 2 trees– Comparable to rendering two binary trees

69

Memory Performance

• Linear memory usage for both– Generic AD approach 5x better

• Marked range storage changes improve scalability– 1GB difference for contest comparison

Conclusions

Future Work

Thesis Conclusions

71

Future Work

• Editing tree topology– Modifying trees graphically

• Updating accordion drawing structure

• Combine generic accordion drawing applications– Tree+Sequence analysis tool

• Link tools with common accordion drawing infrastructure

• Build trees interactively with sequence data• Aggregate sequences based on tree topology

72

Thesis Conclusions

• Generic accordion drawing infrastructure– Partitioned rendering infrastructure– Stable accordion navigation– Split line hierarchy

• Tree topologies in generic infrastructure– Improved marked range storage– Traversal algorithms

• Drawing, picking, layout follow topology

• InfoVis 2003 Contest first place entry– Evaluation of TreeJuxtaposer features– Additional support for searching

73

Acknowledgements

• Tamara Munzner

• Kristian Hildebrand

• Katherine St. John

• François Guimbretière

• Qiang Kong

Questions?

Partitioned Rendering Infrastructure with Stable Accordion Navigation James Slack MSc Thesis...

Documents

Transcript of Partitioned Rendering Infrastructure with Stable Accordion Navigation James Slack MSc Thesis...