title: Improving DrawingContext performance rendering Geometry (Polygons and Polylines)
body: <p>this is my first question, however I'm a long time lurker. I'll split up this into two parts, one part explaining what I'm doing and why I think this is the way to go, the second one being the actual question that I can't solve for myself.</p>
  
  <p><strong>What am I doing?</strong>
  I'm currently developing a framework for rendering 2-dimensional features meant to be displayed in real-time. You can think of an application like Google Maps in your browser, however the framework is meant to render all kinds of geographical data (not just axis-aligned raster data, like those Google Tiles).</p>
  
  <p>The framework is to be integrated into our (the company's) newest product which is a WPF application for the desktop and laptop.</p>
  
  <p>Therefore I chose WPF for actually rendering geometry <em>only</em>; Visibility and Occlusion Culling are done by myself as well as input handling (mouse picking), moving the camera, etc..</p>
  
  <p>Being a real-time application, it need to achieve at least 30 FPS. The framework performs adequate when rendering images: I can draw several thousand bitmaps per frame without a problem, however polyonal data turns out to be a major problem.</p>
  
  <p><strong>The actual question</strong>
  I'm rendering my fair amount of polyline and polygon data using WPF, specifically using DrawingContext and StreamGeometry. My understanding so far is that this is the way to go for if I need performance. However I am not able to achieve the results that I expected from this.</p>
  
  <p>This is how I fill the StreamGeometry with actual data:</p>
  
  <pre><code>using (StreamGeometryContext ctx = Geometry.Open())
  {
          foreach (var segment in segments)
      {
          var first = ToWpf(segment[0]);
          ctx.BeginFigure(first, false, false);
  
          // Skip the first point, obviously
          List&lt;Point&gt; points = segment.Skip(1).Select(ToWpf).ToList();
          ctx.PolyLineTo(points, true, false);
      }
  }
      Geometry.Freeze();
  </code></pre>
  
  <p>And this is how I draw my geometry:</p>
  
  <pre><code>_dc.PushTransform(_mercatorToView);
  _dc.DrawGeometry(null, _pen, polyline);
  _dc.Pop();
  </code></pre>
  
  <p>As a test, I loaded ESRI shapes from OpenStreetMap into my application to test its performance, however I'm not satisfied at all:
  My test data consists of ~3500 line segments with a total of ~20k lines.</p>
  
  <p>Mapping each segment to its own StreamGeometry performed extremely bad, but I kinda expected that already: Rendering takes about 14 seconds.</p>
  
  <p>I've then tried packing more segments into the same StreamGeometry, using multiple figures:
  80 StreamGeometry, Rendering takes about 50ms.</p>
  
  <p>However I can't get any better results than this. Increasing the amount of lines to around 100k makes my application nearly unusable: Rendering takes more than 100ms.
  <strong>What else can I do besides freezing both the geometry as well the pen</strong> when rendering vector data?</p>
  
  <p>I'm at the point where I'd rather make use of DirectX myself than to rely on WPF for me do to it because something seems to be going terribly wrong.</p>
  
  <p><em>Edit</em></p>
  
  <p>To further clarify what I am doing: The application visualizes geographic data in real-time, <em>very</em> much like an application like Google Maps in the browser: However it is supposed to visualize much, much more data. As you may know, Google Maps allows both zooming and panning, which requires > 25 FPS for it to appear as a fluent animation; anything less does not feel fluent.</p>
  
  <p>*
  Sorry but I shouldn't upload a video of this before the actual product is released. You may however envision something like Google Maps, however with tons of vector data (polygons and polylines).
  *</p>
  
  <p>There are two solutions, one of which is very often stated:</p>
  
  <p><strong>Cache heavy drawings in a bitmap</strong></p>
  
  <p>The implementation seems kinda easy, however I see some problems with this approach: In order to properly implement panning, I need to <strong>avoid</strong> drawing the heavy stuff each frame, and therefore I am left with the choice of either not updating the cached bitmap while panning the camera, or creating a bitmap which covers an even bigger region than the viewport, so that I only need to update the cached bitmap every so often.</p>
  
  <p>The second <em>"problem"</em> is related to zooming. However it's more of a visual artifact than a real problem: Since the cached bitmap can't properly be updated at 30 FPS, I need to avoid that when zooming as well. I may very well scale the bitmap while zooming, only creating a new bitmap when the zoom ends, however the width of the polylines would <strong>not</strong> have a constant thickness, although they should.</p>
  
  <p>This approach does seem to be used by MapInfo, however I can't say I'm too fond of it. It does seem to be the easiest to implement though.</p>
  
  <p><strong>Split geometry up into different drawing visuals</strong></p>
  
  <p>This approach seems to deal with the problem differently. I'm not sure if this approach works at all: It depends on whether or not I correctly understood how WPF is supposed to work in this area.
  Instead of using one DrawingVisual for all stuff that needs to be drawn, I should use several, so that not every one needs to be RenderOpened(). I could simply change parameters, for example the matrix in the sample above, in order to reflect both camera panning and moving.
  However I see some problems with this approach as well: Panning the camera will inevitably bring new geometry into the viewport, hence I would need to perform something similar than in the first approach, actually render stuff which is currently not visible, but may become visible due to the camera shifting; Drawing everything is out of the question as it may take ridiculous amounts of times for a rather small amount of data.</p>
  
  <p><strong>Problem related to both approaches</strong>
  One big problem which neither of these approach can solve is that even if the <em>overall</em> frame-rate is stable, occasional hickups, either when updating the cached bitmaps (okay, this doesn't apply if the cached bitmap is only updated when the camera is no longer panned) or calling RenderOpen to draw the visible chunk of geometry, seem to be inevitable.</p>
  
  <p><strong>My thoughts so far</strong></p>
  
  <p>Since these are the only two solutions I ever see to this problem (I've done my fair share of googling for more than a year), I guess the only solution so far is to accept frame-rate hickups on even the most powerful GPUs (which should be able to rasterize hundreds of millions of primitives per second), a delayed updating of the viewport (in the case where bitmaps are only updated when the viewport is no longer moved) or to not use WPF at all and resort to DirectX directly.</p>
  
  <p>I'm very glad for the help, however I can't say I'm impressed by WPFs rendering performance so far.</p>