Splitting a WPF PathGeometry into "tiles"

Question

I have a rather large PathGeometry (over 100,000 points and stroked but not filled) to display for the user, but only a small portion of the path will be visible at any one time. To clarify, the path itself is not predetermined but will be created from data.

The problem: I want to provide very smooth panning so the user can explore areas of the larger path.

I have a possible solution but I'm not sure how to pull it off. I'd like to use a tiling technique--split the geometry into tiles and only load the visible tiles.

So, how do split a stroke-only path geometry into tiles. More specifically, how do I determine the portion of the path that exists in a given rectangular tile?

I know I can use a CombinedGeometry to determine the intersect between the path geometry and a rectangle, but that will include the "walls" of the rectangle (which will be stroked). Is there a better way to tile a stroke-only PathGeometry?

Thanks!

Answer 1

Perhaps instead of tiling just have the one pathgeometry and change the pathdata programatically using databinding or whatever to represent the segment of path you are zoomed in on. A bit like DeepZoom but with paths. This will mean you won't have to mess around merging paths.

I am doing something similar to you but the numbers I am using In my paths are slightly less so I havn't considered using any virtualisation methods. However, I have not noticed massive performance problems. I have a path in a scrollviewer representing about 1000 - 10000 points and it only gets laggy when I zoom in only if the points are very far apart. If the points in the path are relativly close to their neighbours (e.g. a nice sweeping sine wave) then WPF performs some kind of optimisation on them to prevent any percievable lagging.

Eg: this path...

...will take longer to draw than this path:

even though they contain the same amount of points describing it. Although in reality the path needs to start looking like the image below before you notice any difference in performance.

Because the path is representing an audio wave I intend to get rid of any future problems like this by performing some kind of check to see if the points are creating a massive dark blue block and replacing it with something less power hungry but this may not be a sufficient solution for you.

(sorry about the size difference in the images, the bit that calculates the sine wave is out of action at the moment so i've had to use old jpegs)

Answer 2

I was thinking about this myself recently, so perhaps my experiences may help you. Firstly, you can get better performance if you're able to use a StreamGeometry rather than a PathGeometry. I would recommend creating a single StreamGeometry as the Data property of a Path, placing it on a canvas, and then applying Scale and Translate transforms to navigate the shape. I was getting decent performance with 5 or 6 SeriesGeometries each with 1000 points (obviously much fewer than the number you mentioned), though I believe the WPF graphics engine will scale quite well as long as you don't have all the points on the screen at the same time. If you need to support being "fully zoomed out", i.e. all the points would be visible, then I would recommend creating low-res versions of the geometry (i.e. either a simpler set of points or a bitmap) and swapping the high and low-res versions when the zoom reaches some level.

Does that make sense?

Good luck!