[comp.windows.ms.programmer] Slow PutPixel... How to Speed Up?

rev@vax5.cit.cornell.edu (03/18/91)

I am plotting 1000 point on a windows using PutPixel (hdc, x, y, color) in a
loop. This method seems to be awfully slow when updating (redrawing).
The same slow speed if I use Lineto (hdc, x,y).

Is there anyithing I could do to make faster plotting?

I am using BCX with project file with smart callback option.
Running on 386-20MHz in standard mode.

Peter Revesz  Cornell MS&E
              revesz@snoopy.msc.cornell.edu

bcw@rti.rti.org (Bruce Wright) (03/19/91)

In article <1991Mar18.083629.3449@vax5.cit.cornell.edu>, rev@vax5.cit.cornell.edu writes:
> I am plotting 1000 point on a windows using PutPixel (hdc, x, y, color) in a
> loop. This method seems to be awfully slow when updating (redrawing).
> The same slow speed if I use Lineto (hdc, x,y).
> 
> Is there anyithing I could do to make faster plotting?

PutPixel isn't appropriate for bulk drawing (as you have found
out).  It's intended for small numbers of pixels, not 100's or
1000's.

There are three approaches that you may be able to use, depending
on your application and how much trouble you want to go to:

    1)	Figure out the shape of the thing you are drawing and
	use either Rectangle or Polygon.  You can often get a
	significant speedup by breaking up an object into a
	series of rectangular regions and using several calls
	to Rectangle.  Obviously if the object is dynamic, you
	will have to write code to figure out a reasonable way
	to break the object up into rectangles or polygons (it's
	not necessary to find the _best_ way, just one that's
	better than having to do a lot of PutPixels).

    3)	Create a bitmap in memory and manipulate that directly;
	then use BitBlt or StretchBlt to dump it to the screen.  
	Neither is ideal:  if you use BitBlt then you will have
	to deal with device coordinates rather than logical
	coordinates, and StretchBlt may stretch the bitmap in
	unexpected ways and will be less efficient than BitBlt.
	Also, you have to do a certain amount of bit manipulation
	which is slightly inconvenient for small bitmaps but will 
	get unwieldy if the bitmap is larger than 64K.

    3)	You might also want to try Polyline - this is going to
	be faster than a series of LineTo calls but maybe not
	as fast as the other alternatives.

If you're doing something like drawing a graph, the second or third
methods would work (you could create a monochrome bitmap, for
example).  You might want to experiment with different ROP modes
to get different colors on output or to leave the background alone.

Another optimization, which will work for all of these methods, 
including your current approach with PutPixel, is to redraw only
that portion of the window that falls within the invalid rectangle.
That can help a lot for situations when you are exposing part of the
window that might have been hidden by a dialog box, for example, but
it doesn't help at all on the initial display of the window.

Good luck -

						Bruce C. Wright

michaels@cs.hw.ac.uk (Michael Simms) (03/19/91)

Try drawing to a memory device context (see Petzold)
and bitblt'ing your redraw to the real device context
when you update.

	Mike

ebergman@isis.cs.du.edu (Eric Bergman-Terrell) (03/21/91)

How much "coherence" does your graphic have?  In other words are there
large regions of the same color?

If so, there are several graphics techniques that you can use to speed
up drawing (& economize on disk storage too).

Take a look in the index of a good graphics text (look up run-length
encoding & quadtrees).

Terrel