problem with tooltip

I've had this happen too and I think it occurs because a 3D application typically tries to monopolize the GPU, since it's continuously rendering as fast as possible. I found that limiting the framerate helps a great deal in reducing the problems with this. The easiest way to limit the framerate is by setting the presentation interval to One (vsync) on your present parameters.

Thanks for your help remigius!

I'm using DirectX 8. The only way I found to set the presentation interval of the present parameters to vsync as you told me was by setting the SwapEffect value of the present parameters to SWAPEFFECT_COPY_VSYNC. But according to what I understand from the Msdn, this value can not be used in conjunction of the antialiasing.

Furthermore, I don't thing that "manually" limiting the frame rate will help in my case because the frame rate drop is really huge (A scene rendered at 60fps can be rendered at 3fps during the tooltip display).

So I didn't solved my problem yet and I'm looking for another direction...
anyone an idea?

Well, most titles use VSync by default nowadays to combat 'tearing' artifacts, so I doubt antialiassing and vsync are mutually exclusive. Perhaps this may be an issue with DX8, but the DX9 docs don't mention this even though they mention the DX8 equivalent:

Quote:

D3DPRESENT_INTERVAL_ONE The driver will wait for the vertical retrace period (the runtime will "beam follow" to prevent tearing). IDirect3DDevice9::Present operations will not be affected more frequently than the screen refresh; the runtime will complete at most one Present operation per adapter refresh period. This is equivalent to using D3DSWAPEFFECT_COPYVSYNC in DirectX 8.1. This option is always available for both windowed and full-screen swap chains.

I'm not sure if it's just wishful thinking, but even slowing down the render loop manually (having the render thread sleep for a few ms) seems to work. It would make sense, as this will reduce the load on both the CPU and GPU, yielding resources to render effects such as the tooltips or other flashy Windows effects. I agree it's far from perfect, but an overall lower performance (provided the app stays interactive and preferrably in vsync) may be better than 'lag spikes' whenever another window decides to do something fancy.

An alternative would obviously be to render in fullscreen, another one would be to check out D3D10, which should solve this issue with it's new driver model. Provided there are drivers available for it by now [wink]

Quote:

Original post by teo2006 The problem occurs when any Windows "pop up" (such as tooltips or the yellow stuff telling you that you are connected to a network) appears. On some computers this kind of displays causes a major frame rate drop and on other ones simply "destroys" the 3D display by drawing white lines and switching the drawn pixels..

If it destroys the 3d display, then it's a driver bug and should be reported to the hardware vendor (or the driver may need to be updated).

The problem with the tooltips, is that they are not regular windows and also is the case with some special effects done on XP. They don't use the regular windows compositing engine, but go a separate way like CPU compositing. So displaying the tooltip will have a tendency to make things slower (because of the readback on the cpu) and in the case of the multisampled target, the driver may have to downsample on the fly before CPU access which will make things even slower. Of course all of this will depends on your driver implementation, the version of the OS etc. So your mileage may vary.

This should be solved on Vista with the new accelerated compositing engine (no need even for d3d10).

If it's really a problem for you, you may consider rendering to multisample on an offscreen render surface and simply blitting to the non multisampled backbuffer at the end of the frame (with stretchrect). This will force the card to do the resolve before the presenting time.

LeGreg