Quadro2/DCC overlay planes performance

I’m using h/w overlay planes on Quadro boards
to overlay some lines & text onto a radar simulation.

Unfortunately the performance sucks unimaginably.

I’ve cobbled a workaround using pbuffers which gives me something approaching the performance I’m looking for.

I’m hoping for some tips as to how to increase performance using overlays.

General structure is …

// draw overlay


[This message has been edited by newt (edited 06-11-2002).]

Oh, and really I want single buffer on the main plane and double buffer on the overlay - which is not possible.

I draw to the front buffer (with a double buffered pixelformat) for the main plane and don’t swap buffers on the main plane.

so ignore the last 4 lines.

Sorry - how do you edit a post ?

Oh… right I see.

[This message has been edited by newt (edited 06-11-2002).]

Can’t really help you on the overlay planes because I haven’t done anything with them.

Maybe rendering your text and lines into the pbuffer, binding it to a texture, and rendering a quad with that texture over your main output would solve your problem?

Unfortunately because the main part updates much more frequently than the overlay, but only a very small piece at a time.

I do have a pbuffery workaround, it’s just that for the extra bucks, I’d have hoped that the overlay would have been a bit more speedy.

Guess I’ll have to try an 8800 instead.

We use Text and graphics overlays onto screens all the time, however, we do not use overlay planes, we sort the graphics ourselves and draw it all in the primary plane:
DrawUnderlay w/o zbuff write
DrawUnderlay2 w/zbuff write
Clear Zbuff
SwapBuffers & Clear (e.g. set up for next frame)

How much performance are you looking for??

It’s complicated, but it gets the job done, and we are getting about 50fps on our old app, 90 on the new one I am working on. Even more on the Geforce4, but those numbers are for the QuadroDCC, about 35fps on our old Quadro2’s.


Have you considered using the stencil buffer to mask the drawing in the main plane in such a way that the ‘overlay’ information stays visible without having to draw it again?
Don’t know if its quicker, but maybe its worth a try.



The problem with either a sorted approach or a stencil approach is that both the main display and the overlay need to be updated in real-time.

If the main display was refreshed in it’s entirety every update, a sorted approach (or indeed a stencil approach) would work well. However, only a small part of the display is updated (1 radial ~ 0.7 degrees) per “frame”. A whole sweep needs to happen in ~2 seconds. The overlay needs to be doublebuffered (if possible) and updated dynamically (since it’s sort of a gui in nature).

I have some other options but wondered if any driver settings, registry tweaks etc. would have any bearing on how fast overlays work.

what kind of improvements have you done for text acceleration? We have made up most of our speed in accelerating text annotation (heads-up display, and in-scene annotation). Have you tried testing the overlay without text in it to see if it is the presence of the overlay, or the text inside it that is causeing the slowdown?


Could you send me an email about this offline to cass@nvidia.com?

I’ll get you connected with a driver guy that can help.

Thanks -