Recently, while working on a project to visualize .wav files on the Microsoft Surface, I ran into an issue regarding the canvas controls size. While developing this software I am testing with a .wav file about 4 minutes long. Visualizing this file creates a canvas with a width of about 20,000 pixels . . . a fairly large canvas and it will need to support much longer files. I am using a ScrollViewer to maintain a view port over the canvas so a user can scroll through the .wav file. So, the issue that I ran into was that after drawing the .wav file (using Polyline) on the canvas, scrolling across the canvas has significant lag. I already had separate canvases drawing different things in order to maintain the graph while scrolling so, at first, I didn’t think there was much I could do. Here is a little info-graphic for the design:
While playing around with the program I realized that the grid I was drawing in the background did not have to be the entire width of the .wav graph, it only needed to be the width of the viewport and made to be at a static position:
Now, the grid stays within the view port while everything else scrolls past. This small change made an incredible difference. The grid was put into yet another canvas (I already have 4 placed on top of each other). Although the grid lines are thin and a light shade, they obviously require a significant amount of memory to draw and display. I believe I will also be able to apply this technique to a few other aspects of the design.
Here is a video comparison of before and after the simple optimization.
There is pretty obvious difference – lots of lines means lots of resources.
It may be even better to just make an image of the grid and use that as the background, instead of drawing them every time. I will test this next.