slow backbuffer lock

slow backbuffer lock

• Tom Mulcahy - MSFT

  There should be faster ways, but arguably none of them are what I'd call fast. Accessing that type of data (and that quantity) over the system bus is just not optimal usage. If your hardware is on a typical AGP setup then the read-back speed is substantially lower than the write speed (less of a problem with PCI-E though).
  
  Using render-target textures can be slightly more optimal as it's not part of the "core" swap chain mechanism. Also, the flexibility of render-targets allows you to implement your own ring-buffer mechanism which can be very efficient if you don't mind a slight lag.
  
  You might want to consider things at the algorithmic level - see if there is ANY way you can either reduce the frequency or way in which you access the framebuffer data. As I originally implied - it's just not a fast operation
  
  hth
  Jack
  
  
  

• papabear73

  You suggest rendering to texture and then readin back the texture

  I do not understand the last part about reducing frequency or accessing framebuffer data. How would I go about doing that

  Do you know what the expected time would be for reading back a frame of arround 550x700 pixels on agp

  
  

• ggponti

  Thomas Greenleaf wrote:

  I need to grab all my rendered pixels and pass them to a video card in order to show graphics on a tv.

  Why can't you just render your graphics on the video card connected to the TV

  Thomas Greenleaf wrote:

  Is there a faster way of moving my graphics onto my video buffer than lockbackbuffer and lockrectangle

  You can try using IDirect3DDevice9::GetRenderTargetData(). You may need to alternate between destination surfaces in order to get decent performance. If you call GetRenderTargetData() on one surface and then lock and copy the previous surface, you can avoid stalling while waiting for the data to copied from the back buffer. You're probably still going to be disappointed with the performance though.

  
  

• Makover

  Because it is a video card and not a granphics card in the normal sence. This card has buffers which you can write into and then it generates a video signal. It is a complex thing which is used in the broardcast industry. It can not render anything itself.

  I will try your suggestion. Currently I only need to present a new frame 25 times a second, which the card will then interlace to 50Hz PAL, so I am not really in need of anything much faster than that.

  I have seen old code do this with opengl and I assume that directx can do anything opengl can. It is a hardware issue after all.

  
  
• slow backbuffer lock