Re: How expensive are gdi drawing functions?

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance


"Joseph M. Newcomer" <newcomer@xxxxxxxxxxxx> wrote in message
news:0jaua4lfk68rk52b2eh4qi73gpt91kh8ls@xxxxxxxxxx
I posted the preceding memo because a phone call came in that I had to
take. But I wanted
to say a bit more.

For example, if you have data that is only accurate to one part in 100,
you only need a
100-pixel high bitmap to hold it. Anything more than that is just wasted
space. But also
look at the visual effects: if your user can't see a meaningful difference
between
adjacent plot points, or your plotting is quantized so that the only
possible pixel values
are multiples-of-n, then you can use a much lower resolution. For the
medical data,
zooming was expensive (but was also rare) because I replotted the image
with finer
resolution. If I'm showing a 4Mp plot on a 640-wide screen, I cannot
possibly plot more
than 640 points. So I plotted the resolution so that the image that was
being shown had
only 640 points in it (I just chose the maximum screen width as my basis)
and I plotted
one screen-width to the left and right of what the viewer was looking at.
(The result was
that I had accomplished something they had been told was impossible, which
was to get good
scrolling and acceptable zoom performance on a 16-bit machine). So I know
these tricks
work; given that graphics are now about 100 times faster (using modern
graphics cards) and
the machines are at least 20 times faster with over a thousand times the
memory, this
should not be a burdensome problem on a modern machine.

In fact, if you simply blindly BitBlt a window-sized region of your
bitmap, even after a
small scroll, the GDI will do all kinds of clipping to know that it only
has to draw the
rightmost 50 pixels of the graph, and will ignore the request to draw
anything else, so it
is going to be really fast anyway (which is why I suggested not worrying
about the need to
check the bounding rectangle; much of that clipping is now done in
hardware)

So if you are viewing one second of ten on the screen, this means that you
only need to
plot 500 of your 5000 points, which means that you could consider doing
something like
PolyLine (instead of LineTo) and just give it an array from your
designated T0 to T0+1sec,
and let the mapping modes handle all the zooming aspects of the display.
GDI can do this
very quickly. But if you are plotting with 5000 LineTo operations, the
cost is not
actually the graphics, it is the cost of entering the kernel 5000 times.
To a first
approximation, graphics cost is zero, kernel cost is the only significant
factor, when
simple plots like this are involved (you aren't doing 3D surfaces with
Z-axis computations
and surface texturing with light-source diffusion and specular reflection.
Now THOSE
actually take real graphics effort to compute!).

If you are doing LineTo, I'd suggest doing PolyLine first, and see what
effect that has on
your performance. Then worry about using a bitmap.
joe


thanks joe!!! the author was using LineTo for all the points, I replaced it
with PolyLine and extremly smooth now(on my initial test, but looks very
promising)

Nick


On Fri, 22 Aug 2008 16:03:17 -0400, Joseph M. Newcomer
<newcomer@xxxxxxxxxxxx> wrote:

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..

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

Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm


.

Relevant Pages

  • GetPixel Versus Dibsection -- A subtle problem
    ... I have two methods for getting pixel info from an application window. ... The other is to create a bitmap using ... pixels into the bitmap. ... // bitmap must be a dibsection ...
    (microsoft.public.win32.programmer.gdi)
  • Re: How expensive are gdi drawing functions?
    ... one screen-width to the left and right of what the viewer was looking at. ... given that graphics are now about 100 times faster and ... you can reduce the number of pixels by deciding how accurate your data is. ... second window. ...
    (microsoft.public.vc.mfc)
  • Re: Drawing Pixels
    ... Your original question was regarding setting the pixels of the "client area ... window, nor the client area of a window. ... Most drawing is not done using the few methods available in the ... The particular problem you seem to be describing is that you want the Bitmap ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Problem with SavePicture, and a question on new versions
    ... > mode does not have to be in pixels. ... 500 pixels then the picture box will also be 700 x 500 pixels. ... and the bitmap shows ... to be *smaller* than the scale units that the BitBlt API is using ...
    (comp.lang.basic.visual.misc)
  • Re: How expensive are gdi drawing functions?
    ... to BitBlt a bitmap is very ... So what you do is create a bitmap that is 5000 points wide, ... you can reduce the number of pixels by deciding how accurate your data is. ... second window. ...
    (microsoft.public.vc.mfc)