Geeks With Blogs


Locations of visitors to this page

View ► Sanjay Uttam []'s profile on LinkedIn

Add to Google Reader or Homepage

Sanjay Uttam Predominantly .NET

With the release of .NET 3.5 SP1, MS has released a sub-set of the Dundas charting component. They also put together a neat little solution that’ll let you run a number of examples/samples locally so you can get your hands dirty. If you’re looking to do any work with the charting components, or just play around getting these samples should definitely be your first step as the basics will be self-explanatory. The link for that is here.

Now that we got the boring introductory stuff out of the way; the .NET charting component gives you a few different choices when it comes to rendering your chart/image.

Temp directory/ImageTag/ImageUrl Method

This is what I’d consider the simple/out-of-the-box method. Basically, when you create your chart either in the designer or in a code-behind you can specify where the chart should live. This means that ASP.NET will create a chart based on some data that you provide, dump it in a temporary directory, and then you’ll refer to it just as you would any other image.

In other words, your designer markup may look like this:

<asp:chart id="Chart1" 
  BorderColor="26, 59, 105"

And, at runtime, the server will spit out something like the following:

<img id="Chart1" 

Look familiar? That’s roughly what an ASP:Image control would render to had you dropped one of those onto the page. The only difference is that your SRC tag points to a HttpHandler that you specified in your web.config.

In any case, using this method is very straight forward and your client’s browsers will cache your charts just as they would any other image. Of course, the image file that gets cached will look like this:


…The MSDN documentation states that for static data, this caching improves performance. However, in my experimenting even with static data a refresh of the page causes the querystring parameters to change…which means you will need to pull it back down from the server, which also means the browser cached it for nothing. (Although this is what my experimenting indicated, I’m wondering if I missed something. Information to the contrary is welcome…anyone…?...crickets?)

Binary Streaming Method

Now, if you looked at the MS Chart Samples solution, you’ll notice that I’m skipping a couple of “rendering methods” here. That’s largely because I’m thinking if you’re still reading this, you already know you can render a chart in an iFrame, and because their guidance on rendering charts within legacy websites is essentially “use Binary Streaming”.

Binary Streaming is implemented by doing either one of the following

Keep in mind an asp:Image control is getting translated to an IMG tag anyway. In both cases, SomeChart.aspx contains the designer construct for a chart. Something like the following [which is snipped]:

<img src="SomeChart.aspx" width="412" height="296" alt=""/>


<asp:Image id="Image1" runat="server" ImageLocation="SomeChart.aspx" 

Keep in mind an asp:Image control is getting translated to an IMG tag anyway. In both cases, SomeChart.aspx contains the designer construct for a chart. Something like the following [which is snipped]:

<%@ Page Language="c#" Inherits="Samples.SomeChart" CodeFile="SomeChart.aspx.cs" %>
<asp:chart id="Chart1" runat="server" height="296px" width="412px" 
    imagetype="Png" palette="BrightPastel" backcolor="#F3DFC1" rendertype="BinaryStreaming"
    borderdashstyle="Solid" backgradientstyle="TopBottom" borderwidth="2" bordercolor="181, 64, 1">
        <asp:Series ChartTypeName="SplineArea" Name="Series1" BorderColor="64, 64, 64" ShadowOffset="2">
                <asp:DataPoint YValues="6" />

With this method, you’re basically telling the chart that you’d like it to return a Binary Stream (surprise). In essence, the content of the server’s response will be the string representation of the binary object which your browser will render as an image. In a sense, it’s similar to making a request directly to ChartImg.axd directly. The difference here is you’re creating the binary representation of the chart from memory rather than a physical location on disk.

Both of these methods are very easy to set-up and require little to no-thought. I have to admit using a temporary directory feels a little icky but that may just be my OCD kicking in.

There’s another way, though.

If for some reason these two methods don’t jive with you, though, there is another way. It’s sort of hacky – but it works. Basically, you can convert a binary stream to Base64 and return the string directly to the image tag.

<img src='data:image/png;base64, iVBORw0KGgoAAAA[snip]; />
That means that you can generate your chart entirely in a codebehind and then just return the string via an AJAX request.
//Generate your chart
System.Web.UI.DataVisualization.Charting.Chart Chart1 = new System.Web.UI.DataVisualization.Charting.Chart();
//Save it to a stream and return it
System.IO.MemoryStream imageStream = new System.IO.MemoryStream();
Chart1.SaveImage(imageStream, ChartImageFormat.Png);
return Convert.ToBase64String(imageStream.ToArray());

All in all the, binary streaming or the Temp Directory method for chart rendering will probably satisfy your requirements 80% of the time.  It would be interesting to see how each of these scale/perform in a heavily loaded environment.  Hopefully, this provided you with a sufficient high-level overview of your chart rendering options. 

Share this post :
Posted on Thursday, June 18, 2009 2:45 PM | Back to top

Copyright © Sanjay Uttam | Powered by: