Re: How expensive are gdi drawing functions?
- From: Joseph M. Newcomer <newcomer@xxxxxxxxxxxx>
- Date: Fri, 22 Aug 2008 16:03:17 -0400
Depends on what you mean by "drawing". For example, to BitBlt a bitmap is very
inexpensive. So what you do is create a bitmap that is 5000 points wide, and at any given
instant, you will BitBlt a portion of it onto the screen, using whatever the
viewport/window origin and viewport/window extent are.
I was mapping 4 megasamples of medical data on a 100MHz Win16 box doing this, and the
delays were very reasonable. Note also that if the user just scrolls, you would use
ScrollWindow and then use the invalidated rectangle to figure out what subchunk of the
bitmap to transfer if it was too slow with an entire BitBlt.
But first use the in-memory bitmap. Note that there is no reason to "re-plot" the points
because all 5000 points are already there.
Also, you can reduce the number of pixels by deciding how accurate your data is. If your
resolution is 0.01 units, you can probably map it onto a bitmap that is much smaller than
your actual screen because it will not be possible for the user to see tiny differentials.
joe
On Fri, 22 Aug 2008 10:05:18 -0700, "Nick Schultz" <nick.schultz@xxxxxxxx> wrote:
I am trying to improve the performance of a chart control..Joseph M. Newcomer [MVP]
lets say I am graphing data roughly 500 points per second and I have a 10
second window. So thats about 5000 points being represented in a control
thats about 500 pixels wide. As of now, the chart tries to draw every single
point.
I am thinking that an algorithm that turns the 5000 points to 500 points
might improve performance.
lets say the chart is 100 pixels across, and the min(first window value) and
max(last window value) of the xaxis is 0,100, so each pixel represents a
unit. data is coming in at 10 points per unit(assuming they'll have x values
of .1,.2,.3,..etc).
for the entire window there are 1,000 points being represented. But, we want
to translate those 1,000 points to pixels.
if the axis is 100 units across, and the actual control is 100 pixels, so
each pixel represents a unit.
we can then map each pixel to equal the average of points that particular
pixel represents.
for example, pixel 0's y value would equal the average of the actual points
whose x value lies between [0,1) 0 inclusive, 1 exclusive. (or perhaps the
lowest value, highest value, or any other reasonable means)
Not sure if this method will save any time...
Either way, we are still accessing all points that lie within the window,
however we are greatly decreasing the number of points we draw.(in this case
1000 to 100)
we are however doing adding some averaging computation, as well as
determining how to map the pixels.
I suppose it depends how costly a draw operation is.
What are your thoughts? does removing draw operations and adding additional
computation end up being a wash and not notice any improvement in
performance?
Thanks,
Nick
btw this isn't my control, but I have an interest in it that makes it
faster. It is Cedric Moonen's and it's located at
http://69.10.233.10/KB/miscctrl/High-speedCharting.aspx?msg=2690393#xx2690393xx
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
.
- Follow-Ups:
- Re: How expensive are gdi drawing functions?
- From: Joseph M . Newcomer
- Re: How expensive are gdi drawing functions?
- Prev by Date: Re: How expensive are gdi drawing functions?
- Next by Date: Re: MDI without using the child's menu
- Previous by thread: Re: How expensive are gdi drawing functions?
- Next by thread: Re: How expensive are gdi drawing functions?
- Index(es):
Relevant Pages
|
