Double buffered incremental updates

Hello,

With double buffering enabled I am doing (strickly 2D-orthographic) incremental screen updates. Basically, calling a series of rectangle/polygon commands to clear regions of the screen and redraw certain items (i.e. animating a handle on a slider). Upon completion I swap the buffers. This works just fine if the window remains static.

However, if I move the window (not a resize) it seems to shift the contents of the window which is identified on the next incremental update. Basically the new data is off by ~2 pixels in either x or y (or both) to the original data.

Does anybody have any ideas? I have some sample code that exhibits this behavior if anyone is interested.

Thanks,
-Dave

Two things:
You must enforce that the pixelformat you selected has dwFlags PFD_SWAP_COPY set, otherwise it will never work on boards supporting PFD_SWAP_EXCHANGE.

Position invariance should be maintained during window moves, because OpenGL doesn’t really know about window managers and window positions. If you hit this it’s a driver implementation problem.

Thanks for the reply.

I did add the PFD_SWAP_COPY flag which didn’t seem to change anything.

I believe you are correct in stating that it is a driver implementation bug.

It does not work on Windows XP with GeForce 440 Go, but does work on a Windows 2K box with a Riva TNT.

-Dave

Hmmm, from the docs I got, the dwFlags PFD_SWAP_COPY and PFD_SWAP_EXCHANGE seem to be only ‘hints’, and may not bet actually enforced.

My 0.02€.

Do not just set the flag and call ChoosePixelFormat, that function is too dumb. Enumerate pixelformats yourself and check what you got in the pfds.
You probably had PFD_SWAP_COPY formats before, no surprises.

Next step would be to try newer drivers.
With a laptop you need to look for patched *.INF files before you can use the standard NVIDIA drivers.

Just found this (without warranty ) http://homepages.paradise.net.nz/ohau-estate/mobilegpuindex.htm

Originally posted by ZbuffeR:
[b]Hmmm, from the docs I got, the dwFlags PFD_SWAP_COPY and PFD_SWAP_EXCHANGE seem to be only ‘hints’, and may not bet actually enforced.

My 0.02€.[/b]

Right, but if your application relies on PFD_SWAP_COPY behaviour and you get PFD_SWAP_EXCHANGE by accident you’re screwed. Trust me, **** happens and there are a lot of demos and tutorials doing it wrong.

On the other hand PFD_SWAP_EXCHANGE doesn’t really say it exchanges the buffers, it just says that after a SwapBuffer your backbuffer is undefined and you must redraw before the next swap.

Oh, cool the message board has a fricking swear word filter. Let’s see how good it is: **** **** ***** ************.

[This message has been edited by Relic (edited 02-05-2004).]

You’d be much better of updating the entire screen, so unless the performance becomes really horrible, stop causing unnecessary problems

-Ilkka