RE: [GD-Windows] BitBlt() syncing to VBL

[Andy G. <an...@mi...>]

The comment at the end about using 555 buffers is interesting. Maybe
that's why you are using GDI, not DDRAW? - DDRAW blits -do not- do any
pixel format conversion - specifically because generally these are slow
and it would be more optimum to convert your source data.

I have used GDI in the past to do 555 to primary blits with very few
issues, it's very fast, esp. when you involve stretching. However, I
know of very few displays that actually have a desktop running in 555 -
almost everything these days has a 565 desktop (in 16 bit mode). Maybe
the difference between the mac and PC is that the mac has a 555 desktop?
Maybe the PC is being forced to do an expensive conversion from 555 to
565. I bet you would get better performance if you wrote your own
blitter using mmx code to go from 555->565 and 555->8888 and blit to an
off screen buffer then flipped/blit this. If the primary is not 555, 565
or 8888 then just let GDI do it. There are some advantages to 555, like
true gray scales, easier for a single code path etc... - but these are
very very slight.

Andy Glaister.


-----Original Message-----
From: Brian Hook [mailto:bri...@py...]=20
Sent: Tuesday, January 15, 2002 11:27 AM
To: gam...@li...
Subject: RE: [GD-Windows] BitBlt() syncing to VBL


> Yeah, but assuming that the offscreen backbuffer is on the
> video card, the vidmem-to-vidmem blit is so fast that it's=20
> essentially free. Certainly doesn't cost you any CPU time to=20
> queue it up.

If only it were so simple =3D) You can specify where you want your
offscreen GWorld allocated, and all my allocations are hardcoded into
system memory.  DX programming has taught me to stay away from anything
twitchy -- like VRAM/AGP buffers =3D)

> Yeah, the fact that your frame rate is at the refresh rate -
> it would be a stretch to suspect anything else.  Can you=20
> disable bits of your pipeline and log your framerate to see=20
> where the bottleneck is?  i.e. if build your frame but not=20
> blit it to the card, how many fps do you get? What if you=20
> just blit an empty frame to the card every time?  Etc etc.

I'm going to check all that again.  On the DX list this erupted into the
"how to measure time" thread, but for now I'm using QPC and I'll see
what my timings are like for the screen build and the blit.

> I think the recipe for speed is to minimizing blits across
> the bus - composite the new frame in system memory, do one=20
> blit to the back buffer of the video card, then flip or blit=20
> back to front.  You don't want to send something across the=20
> bus that will later be overdrawn.

That's what I'm doing.

> I would bet that CopyBits is heavily optimized, but BitBlt
> should be too.

Not necessarily -- I mean, I would imagine that the Windows engineers
have long ago decided that GDI acceleration probably isn't going to be a
major priority and have concentrated their efforts elsewhere.  The Mac
engineers, however, recognize that they need to look for optimizations
for Altivec anywhere they can since that's a part of their marketing
strategy (the "MHz Myth").

> I think the key for both is to make sure
> you're on the fast path - no transparency, pixel formats=20
> match, palettes (if any) match - so that the function can=20
> just blast bits.

Well, this goes back to the XLTE_ColorTransform thread.  There is some
conversion happening, but it's nearly unavoidable unless I write some
huge explosion of blitters.  Right now I'm taking advice from a friend
to basically do everything in some canonical format (x555 in my case)
and let the back blitter handle conversion.  This is theoretically
slower than making a DDB and then writing every permutation of blitter
necessary to support building my buffers in DDB land.  That just seems
like a failure case waiting to happen though, given the sheer number of
pixel formats that are available.

Brian


_______________________________________________
Gamedevlists-windows mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows