Board index » delphi » DirectX or GDI for normal graphics editing?

DirectX or GDI for normal graphics editing?

I'm in the middle of writing a graphics editor, using GDI functions (or
Delphi encapsulations), and I keep reading about DirectX being great
etc.. Would directX benefit what I am doing at all? Basically I put an
image on the screen and let users Cut, Copy and Paste selection
rectangles, Rotate by any angle, Deskew, Despeckle, and Crop. Draw on
the image (with both black and white pens to have draw and erase),
Select part of the image and drag and resize it. The images I use are
approximately 4 MB in size  currently I'm only doing Black and White
images but in the near future I'm going to include color images and the
size of those will be approximately 96 MB in size. Obviously one of my
main concerns is speed, and what I have now barely cuts it. Probably
because of my lack of experience but partly because of the size of the
image. If I was dealing with smaller images my code would be more than
fine.
The things that I have found slowing my application down are the
StretchBLT functions. when I am pasting inside an image it always takes
2 seconds, no matter the size of what I am pasting. 2 seconds may not
sound like a lot, but other applications I have seen do the exact same
thing in under a second. (I am of course comparing different
applications on the same machine so the length of time is a real
difference.)

Any thoughts?

Sim

 

Re:DirectX or GDI for normal graphics editing?


DirectX is somewhat reduced under NT.

Rene

Re:DirectX or GDI for normal graphics editing?


On Wed, 03 Mar 1999 12:12:01 -0500, Sim Zacks <sza...@imprsv.com>
wrote:

Quote
>The things that I have found slowing my application down are the
>StretchBLT functions. when I am pasting inside an image it always takes
>2 seconds, no matter the size of what I am pasting. 2 seconds may not
>sound like a lot, but other applications I have seen do the exact same
>thing in under a second. (I am of course comparing different
>applications on the same machine so the length of time is a real
>difference.)

>Any thoughts?

There are many missing details about the pasting process.  It's hard
to offer performance suggestions without knowing more about the
problem.  If it takes 2 seconds to paste 1 pixel, there may be a flaw
in your use of the StretchBLT functions.

If you are just manipulating huge bitmaps and stretching them, I'm not
sure DirectX will help you very much.

Chris Hill
Chris...@aol.com

Re:DirectX or GDI for normal graphics editing?


Thanks for mentioning I might have something else wrong in my code.
I went through and timed every instruction and the problem was something I
put in to debug when I first started working on the application, and totally
forgot about. My performance is 100% better now

Thanks
Sim

Quote
Chris Hill wrote:
> On Wed, 03 Mar 1999 12:12:01 -0500, Sim Zacks <sza...@imprsv.com>
> wrote:
> >The things that I have found slowing my application down are the
> >StretchBLT functions. when I am pasting inside an image it always takes
> >2 seconds, no matter the size of what I am pasting. 2 seconds may not
> >sound like a lot, but other applications I have seen do the exact same
> >thing in under a second. (I am of course comparing different
> >applications on the same machine so the length of time is a real
> >difference.)

> >Any thoughts?

> There are many missing details about the pasting process.  It's hard
> to offer performance suggestions without knowing more about the
> problem.  If it takes 2 seconds to paste 1 pixel, there may be a flaw
> in your use of the StretchBLT functions.

> If you are just manipulating huge bitmaps and stretching them, I'm not
> sure DirectX will help you very much.

> Chris Hill
> Chris...@aol.com

Re:DirectX or GDI for normal graphics editing?


DirectX is great at flipping the screen between offscreen screen buffers.
DirectDraw does almost nothing in terms of graphics primatives.  Your code
has to deal with pixel format differences (or be content with emulation
layers) and you have to provide your own primitives for anything other than
bitblt.

Direct3D offers matrix ops, but it is still an extremely low level
interface that assumes you will provide your own "engine" on top.

If you know that you're going to be dealing with very large images, there
are some things you can do to improve UI snappiness.  First, don't draw the
huge image to the screen.  Create a separate DC and bitmap to use for
on-screen editing, and periodically blit that back to the monster image,
say, in the idle loop.  

An extreme measure would be to implement a tiling mechanism so that you can
view sections of the monster image without pulling a lot of the monster
image into physical memory.  A 24 bit per pixel image that is 1024 pixels
wide will require 3x1024 = 3k bytes of memory for each scan line.  Each
scanline is basically on its own 4k virtual memory page.  That means to
blit a 100x100 pixel box from the left side of this image to the screen
would require touching 100 different 4k pages, for a total of 400k of
memory cycling.  If you could cut the monster image into smaller squares or
vertical strips, then the number of 4k pages required to operate on a piece
of the monster image would be many times smaller.  Unfortunately, tiling
makes GDI operations like polygons very difficult.

Don't use the TCanvas.Pixels[] array property.  The Win32 API it uses was
never intended to be performant at scale.  Make sure your monster image is
in DIB format in the TBitmap class, and use the Scanline[] array property
to access the pixel memory behind the bitmap handle.  TBitmap uses Win32
DIBSections to do this, and DIBSections are the fastest way to twiddle with
bitmap bits in Win32 GDI.  The WinG and Direct Draw 1.0 were both
implemented using DIBSections.  TBitmap.Scanlines[] access to pixels is
easily 1000 times faster than the TCanvas.Pixels[] property.

Use GDI raster ops (ROPs) to perform multiple per-pixel operations in one
step.  Ternary ROPs can combine the source bitmap pixel, destination pixel,
and brush color with a full gamut of boolean and arithmatic operations,
many of which are now implemented in video hardware.  We use a ternary xor,
add, xor ROP to bitblit with transparency in one pass in graphics.pas.

Draw as little as you can get away with.  Don't clear the bitmap to black
if all you're going to do next is blit over it again (without
transparency).

Try to pick a pixel format that matches the current video mode.  Most video
cards these days provide direct hardware support for DIBSections - but only
if your DIB pixel format matches the screen's pixel format.  Taking
advantage of video hardware acceleration almost always gives a big
performance jump, enough to offset the added complexity of having your code
support different pixel formats.  However, on truely enormous bitmaps, I
don't know if video hardware will really be able to help.  Video hardware
usually only accelerates what it can operate on within video memory.

Operate on the image in localized chunks.  This gets back to the tiling
idea, but without tiled memory.  If you have multiple operations to perform
on the entire image, perform them all in one small block of the image
before moving to the next block.  This will save you from cycling the
entire swap file into memory for each seperate pass over the image.
Reducing 5 complete passes down to one complete pass of 5 ops per image
region will give you a 5 times performance improvement.  

When the data is larger than available memory, the performance bottleneck
will be the swap file.  Everything you do to reduce swap file thrashing (by
localizing memory access and operations) will dramatically improve overall
performance.

Hope this helps,

-Danny Thorpe
Senior Engineer, Delphi R&D

Sim Zacks <sza...@imprsv.com> wrote in article
<36DD6D61.4A760...@imprsv.com>...

Quote
> I'm in the middle of writing a graphics editor, using GDI functions (or
> Delphi encapsulations), and I keep reading about DirectX being great
> etc.. Would directX benefit what I am doing at all? Basically I put an
> image on the screen and let users Cut, Copy and Paste selection
> rectangles, Rotate by any angle, Deskew, Despeckle, and Crop. Draw on
> the image (with both black and white pens to have draw and erase),
> Select part of the image and drag and resize it. The images I use are
> approximately 4 MB in size  currently I'm only doing Black and White
> images but in the near future I'm going to include color images and the
> size of those will be approximately 96 MB in size. Obviously one of my
> main concerns is speed, and what I have now barely cuts it. Probably
> because of my lack of experience but partly because of the size of the
> image. If I was dealing with smaller images my code would be more than
> fine.
> The things that I have found slowing my application down are the
> StretchBLT functions. when I am pasting inside an image it always takes
> 2 seconds, no matter the size of what I am pasting. 2 seconds may not
> sound like a lot, but other applications I have seen do the exact same
> thing in under a second. (I am of course comparing different
> applications on the same machine so the length of time is a real
> difference.)

> Any thoughts?

> Sim

Other Threads