 |
Desktop Development »
Miscellaneous »
Beginners
Intermediate
License: The GNU Lesser General Public License
Simple Performance ChartBy eclipse2k1A simple Performance Chart/Monitoring Control |
C# 2.0.NET 2.0, WinXP, Win2003, GDI+, WinForms, VS2005, Dev
|
|
Advanced Search |
|
|
|
||||||||||||||||
The Simple Performance Chart is a UserControl that is designed and developed to display varying
performance data like reads per second on a disk drive, the bandwidth for a server, or free CPU resources,
in a visual, clean manner. It can be controlled by a built-in Timer, which makes synchronized display of
values possible. The control offers several formatting options like border style, line colors and
styles, widths, a background gradient, and so on.
The purpose of this article is not only to provide necessary information on how to use this simple control, but also to show how a few interesting issues have been solved. It's neither intended for covering all drawing techniques, nor to provide a ready solution for a production environment.
I found many chart drawing projects on the web, but most of them were intended for displaying complete data
records in countless possible variations. I could not find a good control
that could display a "real-time"
chart of my server's performance, which I collected with the PerformanceCounter
component (or fetched
from other sources). So I wrote my own, and learned a few tricks and techniques, which I'd like to share with you now.
Using the control is pretty easy. Simply link the required assembly reference ("SpPerfChart.dll"),
compile your project, choose the SpPerfChart control from the
Toolbox and drag it into your Form or
any Control. You can edit all of the control's properties in the designer's Properties
panel.
Other than the ability to Clear() the chart from any data, there
is only one public method
available for providing the data: AddValue(decimal). Any
time you obtain a value from anywhere (released by an event, obtained from
recurring routines, and so on), add it to the PerfChart control using
the AddValue(decimal) method. No need to worry about data preparation or display synchronization.
Be sure to set up the PerfChart control properly for your scenario.
Now that we know how to use the control, let's take a look at some interesting issues and how they have been solved.
The actual drawing of the graph is one of the easier parts of the project. I decided to work with two Points,
representing the current and the previous value position. While
iterating through the value collection,
the Point instances are being reused every time. I used a "trick" to avoid an additional condition here:
Instead of skipping the drawing of the first line inside the loop (initial "previous value" is zero), the first line is
drawn outside the control's bounds.
So let's take a look at the essential parts of the drawing method:
/// <summary>
/// Draws the chart (w/o background or grid, but with border) to the
/// Graphics <paramref name="g"/>
/// </summary>
/// <param name="g">Graphics</param>
private void DrawChart(Graphics g) {
visibleValues = Math.Min(this.Width / valueSpacing, drawValues.Count);
if (scaleMode == ScaleMode.Relative)
currentMaxValue = GetHighestValueForRelativeMode();
//"trick": initialize the first previous Point outside the bounds
Point previousPoint = new Point(Width + valueSpacing, Height);
Point currentPoint = new Point();
// Only draw average line when possible (visibleValues)
//and needed (style setting)
// [...]
// Connect all visible values with lines
for (int i = 0; i < visibleValues; i++) {
currentPoint.X = previousPoint.X - valueSpacing;
currentPoint.Y = CalcVerticalPosition(drawValues[i]);
// Actually draw the line
g.DrawLine(perfChartStyle.ChartLinePen.Pen, previousPoint,
currentPoint);
previousPoint = currentPoint;
}
// Draw current relative maximum value string
// [...]
// Draw Border on top
ControlPaint.DrawBorder3D(g, 0, 0, Width, Height, b3dstyle);
}
This looks quite straightforward, and it really is! Take a look at the following source code to learn how to draw a background gradient and the grid. I won't waste many words on it.
/// <summary>
/// Draws the background gradient and the grid into Graphics
/// <paramref name="g"/>
/// </summary>
/// <param name="g">Graphic</param>
private void DrawBackgroundAndGrid(Graphics g) {
// Draw the background Gradient rectangle
Rectangle baseRectangle = new Rectangle(0, 0, this.Width, this.Height);
using (Brush gradientBrush = new LinearGradientBrush(
baseRectangle, perfChartStyle.BackgroundColorTop,
perfChartStyle.BackgroundColorBottom, LinearGradientMode.Vertical))
{
g.FillRectangle(gradientBrush, baseRectangle);
}
// Draw all visible, vertical gridlines (if wanted)
if (perfChartStyle.ShowVerticalGridLines) {
for (int i = Width - gridScrollOffset; i >= 0; i -= GRID_SPACING) {
g.DrawLine(perfChartStyle.VerticalGridPen.Pen, i, 0, i, Height);
}
}
// Draw all visible, horizontal gridlines (if wanted)
if (perfChartStyle.ShowHorizontalGridLines) {
for (int i = 0; i < Height; i += GRID_SPACING) {
g.DrawLine(perfChartStyle.HorizontalGridPen.Pen,
0, i, Width, i);
}
}
}
You probably noticed the gridScrollOffset variable here. It's required because while the horizontal
gridlines always have the same positions, the vertical grid is scrolling with the
chart (line) itself. The
gridScrollOffset value is calculated every time when a new performance value is added.
All animated elements (or just regions) must redraw on each change, which can cause ugly flickering, depending on the redraw speed and size of the canvas to be redrawn. (You could limit the region to reduce the flickering effect, but since it's scrolling, this is not an option for this chart control.) Basically I found two different options which helped in this case:
You can enable double buffering for a control using the following (recommended) method:
this.SetStyle(ControlStyles.UserPaint, true);
this.SetStyle(ControlStyles.AllPaintingInWmPaint, true);
this.SetStyle(ControlStyles.OptimizedDoubleBuffer, true);
Optionally, you simply can set the control's DoubleBuffered Property:
this.DoubleBuffered = true;
I tested the options without a clear conclusion - the results were satisfying in both cases.
The first method is
more specific on how to handle drawing and thus more optimized, which is why I recommend
it. You can find more
information on double-buffering in the References section.
An essential issue was the capability to display arbitrary values in a proper relationship, limited
to the actual viewing range. Defining a fixed Maximum value (for example, a network bandwidth of 100,000 kbits)
would result in unrecognizably flat graph changes when the network reports (as
it usually might) a low bandwidth usage of maybe
10, 100 or 1,000 kbits. With automatic relative scaling, the highest visible value is the measure for all
display calculations. Because it's dynamic, this value is displayed in the upper-left corner of the chart.
The number of visible values is calculated from the control's Width and the (fixed) horizontal value
spacing (in pixels). The highest displayed value results from a simple loop that checks all visible values to find the highest one. Finally,
a few simple mathematical "rule of three" functions are performed to calculate the actual pixel positions.
This is handled by the CalcVerticalPosition() method:
/// <summary>
/// Calculates the vertical Position of a value in relation the chart size,
/// Scale Mode and, if ScaleMode is Relative, to the current maximum value
/// </summary>
/// <param name="value">performance value</param>
/// <returns>vertical Point position in pixels</returns>
private int CalcVerticalPosition(decimal value) {
decimal result = Decimal.Zero;
if (scaleMode == ScaleMode.Absolute)
result = value * this.Height / 100;
else if (scaleMode == ScaleMode.Relative)
result = (currentMaxValue > 0) ?
(value * this.Height / currentMaxValue) : 0;
result = this.Height - result;
return Convert.ToInt32(Math.Round(result));
}
As you can see, the method is quite simple. The currentMaxValue > 0 condition prevents the method
from generating a division by zero. It could have been combined with the ScaleMode comparison in the
else if clause,
but this more structured scheme looked "safer" for future extensions.
We don't have to care about the display synchronization as long we can be sure that our "performance provider" (actually a class
supplying the values) is providing all values at regular intervals. For example, this is very suitable for displaying a
CPU usage chart, where we measure the data once a second, controlled by our custom Timer
component.
But sometimes, we can't tell how regular the intervals can be, or how many values we receive each second. The Simple Performance
Chart offers three synchronization options to address this problem: Simple,
SynchronizedAverage and SynchronizedSum.
Let's take a look at typical examples for each option:
Case example: Web server request duration in a testing environment
We want each single request duration to be visible on the chart, so that we can track down conspicuously long-lasting
requests. We prefer the Simple TimerMode instead of the manual method because the values are reported in real-time and
there could be dozens of requests in a second. Disabled TimerMode would cause a redraw for each value, slowing down
the performance of the whole control. We use the Simple TimerMode to refresh the chart only once a second. On every interval, all
collected values (during the interval) are "flushed" and displayed in the chart.
Case example: Web server download file size statistics
Like in the previous case, the values are reported in real-time. Every starting request triggers the AddValue()
method, providing the size of the requested file (in bytes). Because we only need a simple, statistical overview of the file throughput,
we enable the SynchronizedAverage TimerMode. On each interval it will report exactly one value: the calculated
average of all collected values during the interval time span. Example: The provider reported three file downloads during a second:
100 kB, 200 kB and 900 kB. The chart will display the average of 400 kB.
Case example: Web server simultaneous users load
Let's assume that most conditions can be derived from the previous case. But this time, we are interested in the actual
amount of users requesting our web server per second. (The actual method parameter can even be a hard-coded
1.0).
The SynchronizedSum TimerMode will add all values provided during the interval period.
The Demo Application offers dynamic value generators where all behaviors can be tested and comprehended.
Let's now cover the styling possibilities of our Performance Chart Library.
It's quite an easy matter to allow extensive formatting possibilities for each single drawn element. You can
modify dozens of properties for each single line (like Color, Width or DashPattern, just to name few). I don't want to cover all the possibilities in
this article.
I decided to allow different formatting options per element: The lines (main chart line, optional average-level line, optional grid lines)
can have custom Colors, Widths and DashStyles. Besides that, there
are a few other
settings like the background gradient colors and visibility of gridlines.
It wouldn't be a good approach to put all these possible properties directly into the
control class itself, so I
created a simple class called PerfChartStyle, containing just the formatting properties.
A global instance of this class was created and exposed in a property with the same
name (PerfChartStyle).
Now, this was the resulting Designer Property Bar:
So what's that? The property was not declared as "read-only". Nevertheless, the forms designer doesn't allow a closer look into the style class. Or rather, it doesn't know about it yet. That is what we need to tell the designer.
First attempt:
[TypeConverterAttribute(typeof(ExpandableObjectConverter))]
public class PerfChartStyle
{
private ChartPen verticalGridPen;
private ChartPen horizontalGridPen;
// [...]
A TypeConverter "...provides a unified way of converting types of values to other types, as well as for accessing standard values and subproperties." (from
MSDN). With the TypeConverter attribute we tell the component designer
which TypeConverter we'd like to use. The ExpandableObjectConverter is a converter which discloses its public and visible
properties to a PropertyGrid.
I won't cover the details here; for more information on this topic, continue to the references section.
Now that we set up the right TypeConverter, we're not ready yet: Our changes are only
effective while in design mode!
The UserControl isn't able to keep the changes inside the child properties. That has something to to with
the ComponentModel architecture. Oh well, it's not able yet: Let's move from
attributes
on the class to the actual PerfChartStyle property of the SPPerfChart
control and its attributes:
[DesignerSerializationVisibility(DesignerSerializationVisibility.Content)]
[Category("Appearance"), Description("Appearance and Style")]
public PerfChartStyle PerfChartStyle {
get { return perfChartStyle; }
set { perfChartStyle = value; }
}
The first line does the whole trick. Using DesignerSerializationVisibility.Content, we instruct the
designer's code generator to generate code for the actual child properties, not the class itself.
Here is the final result:
There we go! Expandable style properties, with persisted changes.
This Performance Chart project is a good example of how to create a basic UserControl with custom drawing.
But we are not finished yet: Many ideas for possible improvements are waiting! We can improve the
design-time integration, have a closer look at possible threading issues, and integrate a hundred new features. But if
this simple UserControl can satisfy our needs, our whole effort to implement this solution from scratch is
low, thanks to .NET and its straightforward but powerful drawing capabilities.
There are countless possibilities to improve this control. Here are some ideas,
if you are planning to extend the SPPerfChart.
ChartStyle, like grid size or value spacing...and many more features.
The usual Warranty Disclaimer
COVERED CODE IS PROVIDED UNDER THIS LICENSE ON AN "AS IS" BASIS, WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, WITHOUT LIMITATION, WARRANTIES THAT THE COVERED CODE IS FREE OF DEFECTS, MERCHANTABLE, FIT FOR A PARTICULAR PURPOSE OR NON-INFRINGING. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE COVERED CODE IS WITH YOU. SHOULD ANY COVERED CODE PROVE DEFECTIVE IN ANY RESPECT, YOU (NOT THE INITIAL DEVELOPER OR ANY OTHER CONTRIBUTOR) ASSUME THE COST OF ANY NECESSARY SERVICING, REPAIR OR CORRECTION. THIS DISCLAIMER OF WARRANTY CONSTITUTES AN ESSENTIAL PART OF THIS LICENSE. NO USE OF ANY COVERED CODE IS AUTHORIZED HEREUNDER EXCEPT UNDER THIS DISCLAIMER.
This software is licensed under the CC-GNU LGPL.
General 
News 
Question 
Answer 
Joke 
Rant 
Admin
|
PermaLink |
Privacy |
Terms of Use
Last Updated: 8 Feb 2007 Editor: J. Dunlap |
Copyright 2007 by eclipse2k1 Everything else Copyright © CodeProject, 1999-2009 Web18 | Advertise on the Code Project |
Really interesting to hear that the original basic implementation had also best performing parts - I wouldn't believe that (not at all that a Matrix transform has those drawbacks). But oh well, we all learn, and in this case, we seem to have learned both a lot of things. Thanks for your outstanding commitment!
Its a great work . am giving 5 to this