Does anyone know what the fastest way is to Blit an image over to the screen using Doubled buffered techniques?

Also, anyone ever clock the standard GDI BitBlt against the DX7 Blit? Which one is faster.

The reason I ask is that I am creating a game editor and when my Bitmaps get fairly large I have a huge performance hit.(very sluggish). Not really an issue if I am using BitBlt, but when there is zooming involved and I have to use StretchBlt() and zoom is at 2:1 - that is a huge slowdown. I use a Memory DIB Section to hold the graphic and GDI blits to move it to screen.

What is the fastest possible way to move bitmaps to the screen(no masking, just straight copy). I also need to have direct access to the Bitmap bits as well - this is why I use a DIBSection

thanx for any info guys
Posted on 2002-01-16 17:48:34 by Rockinronstar
I know someone else here did some timings once which showed that of the gdi functions BitBlt is the fastest. I don't know how DX8 would compare though.
Posted on 2002-01-17 06:27:47 by Eóin
Afternoon, Rockinronstar.

I guess it depends on how you're going to use it.

Any type of StretchBlt proc is slow - even in DX. I think Eion's right - the GDI call is faster.

If you want to make it *the fastest* way possible, then I'd suggest creating a D3D proggy, and just *zoom* in on the *texture*.

hrrmm. How large is your bitmap?

Posted on 2002-01-17 06:52:19 by Scronty
Hi !

If your hardware is capable of doing stretch-blits not only factorized by powers of 2 than the DX-methods will be faster.

The normal Blit-functions in DX are also faster, because GDIBlits do much format-checking and transforming and all this happens in system-memory. To do really fast blits put all your blitter-objects into the video-mem.

Greetings, CALEB
Posted on 2002-01-17 07:04:26 by Caleb
Hey guys, the texture(bitmap) can be up to 2048x2048 and will blit/stretch as much as can be seen to the screen. I also need to maintain accuracy of pixel placement and pixel color as there is also a mini pixel editor in place as well and you can imagine the importance of the pixel your editing is actually there and is that color.

Would it be faster to use D3D and make the bitmap a texture and then render that to a quad that covers the window client area? I know you can set the renderer to maintain accuracy when it stretches textures. One big question is this - how the heck do you do the texture/quad idea, hahaha

never used D3D before on Direct Draw on DX7
Posted on 2002-01-17 07:14:09 by Rockinronstar
I "believe" that using a Device Dependant Bitmap (DDB) is faster than a DIB Section ?
Posted on 2002-01-17 07:32:51 by BradB
Afternoon, Rockinronstar.

heh. My last post is based on my experience with a cr*ppy vid chip (SiS 630). That's probably why I don't see any difference between stretchblitting with GDI or DX.:grin:

hrrmmm. Doing that texture/quad thing is quite easy.
First: you make a quad (i.e. two triangles).
Next: you set the *texture coordinates* to each corner of the quad.

at this point; if can you render the quad as normal (i.e. move the quad in 3d space with a matrix, set the texture with *SetTexture*, and draw the quad with DrawPrimitive), then the image will be display where-ever you've placed it in space.

Next: zoom in/out by moving the quad along the Z axis (or whatever axis you've decided to be *into/outof* the screen).

Next: select where you want to draw a pixel by using a *pick* algorithm (there's a Pick example on my w/site, or take a look at M$s' Pick example). D3DXIntersect returns information which helps in deciding where on a triangle you've *clicked*.

Then: you've got to figure out how you want to display everything. Maybe a "close-up* view on the side which displays the pixels under the cursor?

heh. After all that, you may which you stayed with GDI:grin: .

Posted on 2002-01-17 08:12:34 by Scronty
hey Scrony, I hear ya - may be afraid after this, haha

Well I need optimal speed on this app. And if I can get my hands on some acceleration then I am game.

Do you know of any code examples that show how to do what you mentioned. Recommend any good tutorials/books. I only have DX7 DirectDraw experience. Never done any 3D ever
Posted on 2002-01-17 08:31:47 by Rockinronstar
Do the DIBs need to be streched dynamicily, ie a different size each frame.

If not,you could StretchBlt them to a memoy bitmap (not a DIB) with the same format as the main Dc you are currently stretching them to, then you can BitBlt from the memory DC which would be quite fast.
Posted on 2002-01-17 11:38:35 by Eóin
Afternoon, Eion.

Would creating such a large dc be a problem? X2 zoom would need a dc of 4096X4096. X4 zoom...hrrmm... larger still.

Posted on 2002-01-17 11:52:50 by Scronty
Could aways partition the image and load only the region used.
Posted on 2002-01-17 11:59:07 by bitRAKE
Afternoon, bitRAKE.

Yeh. that's similar to what I thought, too. Just zoom the area you're working on, onto the memdc. Only update when scrolling (maybe scroll in sections).

If you're working on a large image, you're usually not scrolling madly back and forth to opposite sides (well.. maybe sometimes ;) ).

In any case, you wouldn't zoom the *entire* image, anyway.

Posted on 2002-01-17 12:08:40 by Scronty
the bitmap does change dynamically. They have the ability to zoom from 1:1 to 32:1

Also, since it has bitmap editing features, it would require updating the data, the stretched data and the original bitmap.

I can always save time by boost efficiency by doing smart scrolling - screen to screen for the parts unchanged and then update from the original where needed. I actually do this partially right now. And also only draw the rect bounds in PaintStruct.

i think I like that quad idea though. Just don't know how to use D3D. If I can get some samples/tutorials on how to use it then I should be fine. Hope its not as bad as DX7. I learned all that from the SDK help file and boy oh boy, what a headache at the end of it
Posted on 2002-01-17 12:14:28 by Rockinronstar
Hey Scronty, thats actually what I had implemented from the start. Only stretch what is going to be visible. That is definately the most realistic approach. But when you got a maximized window and a res of 1200x800(which we use mostly). Thats an awful lot of "viewable" area, haha. Thats where I need the efficiency to come through. Quad/Blit/StetchBlt - need the best one for the job and it has to maintain perfect pixel accuracy since it also is an editor. StretchBlt maintains it fine, Blit seems to, except when I specify DDSCAPS_LOCALVIDMEM with the primary surface. This seems to cause the pixels to almost antialias somehow. No matter how much you "zoom" you never see pixels - it adds gradients to smooth things out(not sure why).

Then there's the quad/texture idea. This one I haven;t tried as I am a D3D pre-newbie
Posted on 2002-01-17 12:20:49 by Rockinronstar
The FASTEST blit ever is the 2D one done by the video board's hardware bitblt engine. Nothing can beat that, not even 3D (well to be honest 3D calls the same engine, but does other things also).

Problem is IF you have acces to it :)

IF you are Using DirectX, this means you MUST place the bitmap into a videomemory surface. After that you can use Blt(stretch) or BltFast (no stretch) to place parts from your bitmap into/onto the Primary buffer (ie on screen).

Of course you must have enough videomemory to hold the bitmap and the primary buffer (at least) in the video memory (calculate using Pitch and not screen_dx)

Take care with huge bitmaps some drivers (and i mean many of them) do not support wide surfaces, that is they do not support surfaces that are wider than the crt resolution ...sorry, i gusss you will have to split the original bitmap into several "tall "slices in such case...

Again some OS (aka Win9x) do not support height greater than 32768 ... so again split if you need to

Besides i, myself whould not make operations directly on GDI bitmap or Dx surfaces, i would make the in a memory arrea (so to speack a kind of my owm raw memory DIB) and then make updates to the screen.

I would create the DIB section etc only when i will save/load the image from HDD.

But even there i (IMHO) will like to load BMP format from file (and save) using my own file operations.... after all BMP file format is not very complicated and you may not want GDI to make color conversions/matching while loading image :)

Also please do not read the pixels directly from screenn like IfranView does ... onmy 800x600x16 standard resolution the get matched with wrong values :(
Posted on 2002-01-17 13:17:21 by BogdanOntanu
nope, wouldn't read from the screen in anything less than 16 Bit. Anything less than that are mapped system palette colors. May or may not be the actual color value! Dangerous assumptions if you do that I think personally.

So Blit is faster then. I will try and convert things over to DirectX then.

Our stuff only works in Win2K and above so not worried about memory bufers and also we use the best video cards. Its all internal used software
Posted on 2002-01-17 15:16:34 by Rockinronstar
Rockinronstar, have you ever tried the standard windows' zooming technique? I never used it and I don't believe it will be faster than DX, but who knows :grin:? Using this technique you will also have a single bitmap to update, not two. For "standard windows' zooming technique" I mean using SetMapMode, SetViewportExtEx, SetWindowExtEx, SetViewportOrgEx (for panning the image), and so on... I also have an old MFC example from a 1996 magazine, if you want to look at it feel free to leave me a PM.
Posted on 2002-01-18 04:49:32 by LuHa
Hey LuHa, I had looked into and played with the Map Mode methods. What I found was ease of use when dealing with zooming , but must be loaded full of overhead since it worked so slow. haha My editor is so CPU intensive that I need to use the fastest methods possible. I usually have to resort to managing everything with code myself.

I have converted my app window over to use DX7 and now I blit everything using Blit().

There is one strange thing though and I have no idea what causes this... When I use Blit() and there is stretching involved, the image doesn't seem to stretch properly. If I zom in on a particular area, I should see wel defined pixel blocks, but instead I see a blur?? It almost looks like Blit() anti-aliased the image. It added lots of clors to "smooth" things out. I am not sure why Blit() would do this though. I am using DWRop set to SRCCOPY.

I see that there are specific DX Rop's but I have no docs on what they are, so I always leave those out. I hoped that SRCCOPY would just stretch it without anti-aliasing/smoothing things.

Anyone know what you need to do to get a "real" stretch that is very accurate to the original image that was being copied?
Posted on 2002-01-18 06:25:50 by Rockinronstar
Just use the GDI StretchBlt, It doesn't AntiAlias, I wish it would :)
Posted on 2002-01-18 06:46:26 by BradB
Afternoon, Rockinronstar.

It'll have something to do with the filter flags.

I dunno what it is for DX7 Blit().

Posted on 2002-01-18 06:51:53 by Scronty