Chris Crowe asked:
> Is there a faster way of drawing to the screen?, I have to draw
> to the bitmap becuase if I do not the screen flickers rather badly.
The primary difference between drawing to an offscreen bitmap and directly
to the screen is in the device drivers involved.
When you draw to an off screen bitmap you are utilising the the memory
device driver to translate the GDI calls into altered pixels. Obviously this
is all done by the CPU turning the GDI primitives into altered memory
states, and requires hitting the L1 and L2 caches, the main memory bus and
your DRAM.
When you draw to the screen you are utilising the video device driver for
the card(s) in your machine. If these cards drivers provide hardware
acceleration (and what cards don't these days?) your GDI primitives will be
performed using the hardware accelerated line, font and filling directly
into the fancy video RAM used by the card.
So with any modern video card drawing directly to the screen is cheaper on
CPU time, and takes advantage of hardware to perform most common drawing
operations. That's why all my drawing code goes directly to the screen, and
off screen bitmaps are not used.
But what about the flicker? The flicker is caused by erasing a drawing area
to the background color before refilling with the foreground stuff. This
causes unchanged areas that are being redrawn to vanish and repaint, and if
the monitor repaints during this period then you see the alteration taking
place.
The solution I use it NOT erase the background before drawing into it (and
tell windows not to erase it either! [see the WM_ERASEBACKGROUND message]),
rather I create a region representing the area requiring painting, and as
each of the foreground text objects is draw, I substract this from the
region. At the end of the foreground drawing process anything left in the
region is erased to the background color.
The cost in doing this is that there is acertain amount of complex region
manipulation that needs to be done by the CPU, but the using hardware
acceleration appears to gain more than that lost by the region arithemetic.
The only other issue is that some times in a busy machine invalid areas of
you program may not be painted for a second or two as the WM_PAINT message
has a much lower priority than other messages, and the unerased portions of
the invalid area tend to sit about for a while.
Cheers, Max.
---------------------------------------------------------------------------
New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
Website: http://www.delphi.org.nz
