Full WPF Support

brendan · March 22, 2016, 7:12am

Hey

I've been working with the WPF Map control pretty much non-stop since it was released a few days ago, and I thought now is a good time to bring up some thoughts / suggestions. Seen as the control is still in the development phase, I suppose they are more relevent now then they will be in a few months when everything is released.

What's great about the two map controls at the moment (Winform & WPF control) is that they are almost identical to work with. This means that if you can work with the one, it's easy to move to the other. Herein lies the problem.

If you want to draw a line with a custom style on the map (CreateSimpleLineStyle), you have a choice of the following parameters in the constructor:

GeoColor centerlineColor,

float centerlineWidth,

LineDashStyle centerlineDashStyle,

GeoColor innerLineColor,

float innerLineWidth,

LineDashStyle innerLineDashStyle,

GeoColor outerLineColor,

float outerLineWidth,

LineDashStyle outerLineDashStyle,

bool roundCap

What more could you want to do with a line?

Seems like we have quite a lot of options... and indeed there are. But in WPF we get far more that the ability to draw a line the way we did in GDI+. What if we wanted to put a radial gradient in the line? Give it a drop shadow? Add a trigger so that the line would grow and shrink ever so slightly to give it the effect that it was breathing?

Well in WPF, to add a gradient fill you would access the stroke property on the line... and add a RadialGradientBrush. Here's the XAML for a sample... which we could easily do in the code behind as well.

Line X1="10" Y1="10"
    X2="50" Y2="50"
    StrokeThickness="4"
    Canvas.Left="100"
    Line.Stroke
      RadialGradientBrush GradientOrigin="0.5,0.5" Center="0.5,0.5" RadiusX="0.5" RadiusY="0.5"
        RadialGradientBrush.GradientStops
          GradientStop Color="Red" Offset="0" /
          GradientStop Color="Blue" Offset="0.25" /
        /RadialGradientBrush.GradientStops
      /RadialGradientBrush
    /Line.Stroke
  /Line

[I removed the tags because they aren't wanting to be displayed]

<line x1="<span" style="color: maroon;">
<line.stroke><radialgradientbrush.gradientstops> </radialgradientbrush.gradientstops>

</line.stroke>
</line>

To get the growth effect we would add an EventTrigger to the Line's Triggers collection and change the stroke's width using a Double Animation. Also just a few lines of code.

With the service pack released, we can now write HLSL pixel shaders that we can add to our application. This means that we have access to hardware rendering to give us amazing effects. It takes one line to add a pixel shader to any WPF element (element.Effect = ...).

Take a look here: rakeshravuri.blogspot.com/2008/07/wave-reflection-shader-effect-in-wpf.html

We could add a waves to our oceans in the map even! Not that we'd want to... but we could, if we had access to those properties.

All of these things are easily possible... but only if we open up these properties on the underlying shapes that we add to the layer.

WPF's power comes packed in a few inherent pieces of functionality: Styling, Databinding and Animation. What we effectively have here in this WPF control (which is great so far... don't get me wrong) is a GDI port with none of what makes WPF powerful available to the user.

Is there something we can do to open up this control a little?

David · March 22, 2016, 8:09am

Brendan,

   You bring up many good points on the virtues of WPF.  The problem that we have had with it in the past was that it was so very slow.  When we started building the Services Edition, long before the WPF Desktop control, we created a WPFGeoCanvas.  This uses native WPF drawing and even using Microsoft’s best practices it was far slower than GDI+ drawing.  We were stuck, I mean yes we want all the all features but after being in this business a long time we also knew people wouldn’t stand for 3 second maps that draw in 1 second with GDI+.  We found that to get the advantage of hardware acceleration we have to draw directly to the screen, this causes lots of other issues with refresh requirements.  Don’t even get me started with how slow it is if people don’t meet the hardware requirements.  It seems like Microsoft pull all their effort into 3D animation.  They also seemed to target flashy looking forms that are not that complex.  They certainly didn’t have map drawing in mind.  There is also the issue with being able to support other features like re-drawing certain layers of the map on top of or in between other layers.  To do this we need to render to a bitmap and then we can support this kind of layer dynamic refreshing.  There is also the caching issue where people want local caches to speed things up and this needs to be drawn to an image file.  With lots of technical problems with WPF being slow we decided to do the control proper in WPF and the rendering in GDI+.  From surveying our customers we had so many of them saying they just want the Desktop 2.0 in a native WPF control as it affords them benefits over using a Winforms control in WPF.

   That is how we got to where we are now.  That doesn’t mean we can’t change this in the near future.  The great thing is that we have control of this thing and with feedback like yours we can push the envelope on this thing and get the best of both worlds.  Map controls are our business and we don’t have some bean counters saying that we need t do this or that, we are committed to have the best map controls out there.  What I would like to see is both methods in the future.  If you need the fastest drawing  then use GDI+, if you want pulsating streets then us WPF drawing.  We should be able to support this with some work.  We would need to come up with WPF’s own styles as well.  Currently the styles we designed needed to be the lowest common denominator so that they could apply to lots of different drawing systems, GDI, GDI+, PDF, SVG etc…  This doesn’t mean we can’t have really cool WPF styles though.  What I would like to do if possible is talk with you on the phone and get some direct feedback.  If you could send an e-mail to support@thinkgeo.com and leave your phone number with the best times to call.  Have them forward it to David please.  Also I am out of the country traveling in but will be back in the US around the end of the month.  Let’s set something up for then.

David

brendan · March 22, 2016, 8:09am

Thanks for the response David.

It’s great to have a deeper understanding of the control and its history. My first question when I heard about the control a few months ago was performance… WPF is not as good as GDI+ for plotting large numbers of points. I think there are probably a few things we could look at that could help us create a more interactive control, like combining the two techniques (leave GDI for the base map, and use WPF for the “dynamic” elements like runner’s tracks and cars etc - items that have few points but a lot of potential interaction).

I’ll send an email through to support with my contact details on Monday.

Thanks again David.

David · March 22, 2016, 8:09am

Brendan,

   This is just round one for the Desktop Edition and I think there are a million ways to make it better.  I am big into transparency and feel the more you know the better we can make a product you want.  I like the idea of leveraging the really cool features of WPF for the flashy things and try and keep the boring stuff in GDI+ or GDI.  The great thing about our platform is that we have flexibility with it.  There are other drawing systems besides GDI+ we are playing with and a lot of cool things in the pipeline.  It’s also good to hear our customers take on things because we can match their expertise with ours.  There are certainly things about GIS and the way maps work that limit our choices but no matter what we want to be transparent the choices we make.  Being a developer myself there is nothing worse than asking a company “Why can’t you do X” and getting either no response or a “We don’t want to do it that way.” type of answer.  I have even seen forums from some of our competitors that say things like “Do not address questions to our staff as we do not check the forums” “Do not ask questions that the community could not answer.” .  I was so surprised by this I wondered why they even bothered to have a forums.

   I think our companies focus on the discussion forums really pays.  With other companies the discussion forums were always looked at as a necessary evil.  They made it a place where the company tried to get free community support from others and they put low experience support people to answer the questions.  We felt that we were wasting a huge resource for information about what our customers want and how to make our API better.  We have top notch people answering questions here.  What we found over time that we have some really smart users and they give great feedback if anyone would bother to listen.

   I look forward with speaking with you in a few days.  I better go as I am prone to writing chapter like posts.

David