partitioned rendering infrastructure with stable accordion navigation james slack msc thesis...
Post on 22-Dec-2015
217 views
TRANSCRIPT
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
8
TreeJuxtaposer
• Limitations– Scalability
• Maximum dataset size: 500,000 tree nodes• Slow rendering for large datasets
– Tree-specific Accordion Drawing• No separable infrastructure
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
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
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
24
Split Cell Child Region
• Center split line can move anywhere
• Left child of parent is bounded– Parent split line bounds all descendants
25
Split Cell Child Region
• Center split line can move anywhere
• Left child of parent is bounded– Parent split line bounds all descendants
26
Split Cell Child Region
• Center split line can move anywhere
• Left child of parent is bounded– Parent split line bounds all descendants
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
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
Accordion Drawing InfrastructureTree-specific Accordion Drawing
InfoVis 2003 Contest EntryEvaluation of Generic Infrastructure
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
Accordion Drawing InfrastructureTree-specific Accordion Drawing
InfoVis 2003 Contest EntryEvaluation of Generic Infrastructure
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
Accordion Drawing InfrastructureTree-specific Accordion Drawing
InfoVis 2003 Contest EntryEvaluation of Generic Infrastructure
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
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