Question

I’m running into an odd problem where the IDXGISurface BackBuffer description doesn’t match the size of the SurfaceImageSource that created it. I can’t find any documentation on why this would be the case, but I’m seeing subtle variances (eg: 1366x768 becomes 1376x768, 2560x1440 becomes 2592x1440 and so on).

I have the source for an isolated repro here: https://skydrive.live.com/redir?resid=16E5F6030DCB8991!25573&authkey=!AF0Y3h0-ufLPubs&ithint=file%2c.zip

Any ideas?

Was it helpful?

Solution

This is expected. When using SurfaceImageSource, the DXGI surface you get is often a reference to an atlased surface. XAML does this to improve performance and reduce memory overhead (especially for apps that use many small SurfaceImageSource elements).

Applications are expected to render into a subset of this region based on the returned offset value of BeginDraw. Also note that you should never cache this value or the IDXGISurface* since XAML may give you a different offset or atlas on subsequent calls to BeginDraw.

In your case since you only have one SurfaceImageSource, the atlas usually roughly matches the requested size. However, if you had two SurfaceImageSource objects each 1366x768, it's likely you would get back a single IDXGISurface that is 1376x1536, where calling BeginDraw for one returns (0,0) and BeginDraw for the other returns (0,768). Those points serve as the origin at which you should draw into the surface.

One other thing - considering the sizes you've tried, it looks like you're trying to create a full-screen SurfaceImageSource. Depending on the scenario, SwapChainPanel might be more appropriate, and actually gives you a properly buffered swap chain.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top