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

[Brian H. <bri...@py...>]

> A lot of what you're describing is surprising.  When I was 
> doing Mac stuff PCI video was the high end and NuBus was more 
> common, so that's a ways away from your G4 - but I never had 
> an app that ran faster on the Mac than the PC.

Well, Macs have gotten out of the Stone Age and are somewhere in the
Iron Age, so they at least have AGP now =)

> Also, what you say about DDraw blits seems strange.

Well, it was a bit of an unfair comparison.  With DDraw I was always
assuming that the source surface had transparency, even if it didn't, so
I'm sure it was going through a slower path than necessary.  With my GDI
blitter, I have separate opaque and transparent blitters.
 
> You also don't mention if you're page flipping, which would 
> obviously lock you to the refresh rate.

Nope.  This is on OS X using off-screen Gworlds and CopyBits().  This is
pretty much the MacOS equivalent to DIBSections and BitBlt().  In fact,
I should have even WORSE performance under OS X because I'm actually
triple buffering -- my blit goes into the window's off-screen
backbuffer, which is then blitted by the OS later.  Under Windows I'm
just going straight from DIB section to the Window's front buffer (in
theory).

My guess is that there's still some VBL action going on somewhere (note:
the Mac also VBLs, even though I'm getting 125fps, but the triple
buffering is probably accelerating things by allowing multiple blits in
a single refresh?), since I'm locked very close to my monitor's
ostensible frame rate.

I've tried disabling all the various "sync" parameters in the driver
properties, but to no avail.

I do find this quite a bit odd simply because I was expecting to do a
lot of optimization work on the Mac since the Mac has a slower clock
speed and significantly less memory bandwidth.  My nearest guess is that
I'm either doing something terribly wrong on the Windows side, or the
Mac has some kind of mad, stupid Altivec optimized memcpy()/CopyBits().

-Brian