locked
SwapChainPanel and desktop, and tiled resources performances RRS feed

  • General discussion

  • Hi!

    I'd like to discuss a few points about the new features in the actual dx11.2 update.

    Firstly, I had great hopes when it was announced of seeing the SwapChain(Background)Panel available for desktop technologies like WPF, and not clutched to Windows Store apps. The reason is that I'm primarily looking for such a feature with WPF is that D3DImage has too many drawbacks for the kind of programs I work on (and I'm not interested in making store apps). The swap chain background panel is awesome in store apps in terms of performance and XAML integration, and I find it a huge lack not being able to do the same in WPF. I do recall seing the new SwapChainPanel flagged for desktop too on 8.1 on its announcement over on the MSDN (http://msdn.microsoft.com/en-us/library/windows/apps/windows.ui.xaml.controls.swapchainpanel.aspx) but I might have been mad or sleepy. Anyways, it's a bit of a deception not being able to use it desktop-wise.. if you guys have intel on that for RTM (ie. can confirm it will/won't be available for desktop) and/or solutions for WPF that don't make use of D3DImage, I'd be delighted.

    Secondly, I'd like to discuss the tiled resource feature performances. Honestly, I ran the store C++ sample on a Vaio Duo (i5, 4gigs of ram, HD4000 graphics, same as a Surface Pro), and it runs like crap. Processor usage goes batsh*t crazy even when the camera is idle and I hardly get much more than ten images per second, except when I'm not looking at the virtual Mars. Sure, it's a game technology, but I already have a good rig compared to "standard" Windows 8 configurations, not even talking about Windows RT stuff. Now I haven't tried deploying it elsewhere, on smaller or bigger rigs, but I find this performance hit pretty disturbing for a technology supposed to optimize and help loading a whole lot of vertex and texture data to the graphics card. Is it something isolated or can you confirm you have problems on similar rigs? Will performances be reworked for RTM? It's a very interesting feature, and having it natively built into DirectX is great. But it's impractical right now for the kind of stuff I do, which I can understand, as it is a preview, of course.

    Any ways, if you want to drop a line or two of your opinion or feedback on that stuff, feel free to come and discuss it!

    Wednesday, July 24, 2013 2:36 PM

All replies

  • Hi Cubeslam,

    Please post separate issues in separate posts. Questions or commentary on desktop API should go to the Windows Desktop Development forums. WPF questions and commentary should go in the WPF forums. The Windows Store apps for Windows 8.1 Preview forums are specifically about Windows Store apps.                            

    The SwapChain(Background)Panel API are part of Windows.UI.Xaml. They are not available for WPF. I haven't seen anything suggesting otherwise. If you have, it was in error.

    Regarding tiled resource performance, I don't think the HD4000 supports the TiledResourcesTier so the TiledResources sample will fall back to the software WARP device and be highly dependent on the CPU. The Vaio Duo has an i5U chip which is optimized for power usage rather than performance.

    I don't have an i5 or an HD4000 system handy, but the sample performed well run directly on my i7QM laptop (significantly more powerful than your Vaio) using WARP.

    --Rob

    Thursday, July 25, 2013 3:18 AM
    Moderator
  • Hi Rob,

    thank you for your answer. I posted on these forums because I couldn't find any suitable forum for this DirectX/WPF support on 8.1. I'll repost it on the desktop dev forum. Still, I find it sad that it hasn't been "ported" to WPF, it would really be a great plus. I've already seen the uservoice on that matter, but not much reaction on this one either.

    Regarding the TiledResourcesTier, I find it weird that such a great feature, for an OS where 3/4 of clients have rig lower or equivalent to mine (ie. ultrabooks and tablets) requires such a high configuration. I know it's a specific technology, made for heavy demanding games, but that's technicaly not the prime market on the Store right now, and other applications of this feature I can find of (ultra detailed google earth like apps, for example) are just not possible because of these demands. And frantically, I've been working on equivalent features for the past few months, to get them working on small rigs, and the stuff I run is far more demanding yet still fluid than the Mars tiledresources sample. I sure hope this is part of the preview, and hasn't been looked into yet, else the feature won't be of much use on Store Apps. Not regarding desktop games, which I think will take advantage of this technology of course. That's my two cents, and I'd like to discuss it.

    Thursday, July 25, 2013 6:58 AM
  • D3DImage is also specific to Direct3D9/Direct3D9Ex, and does not make use of Direct3D 11.x. XAML and Windows Store apps are Direct3D 11.x based.

    Have you considered using a different interop solution to gain access to Direct3D 11.x in your Win32 desktop apps? SharpDX or SlimDX are good options.

    Friday, July 26, 2013 5:26 PM
  • I'm already using SharpDX as a matter of fact, but the condition is to be able to build WPF interfaces over it. I've explored several solutions, but none of them allow me to push the maximum of both worlds. I can of course use dx11 api inside a WPF host, but the feature level gets stuck at 10.1 because it remains a D3DImage binding, so it's mainly a commodity. If you have any more flexible idea, I'll take it.
    Saturday, July 27, 2013 4:45 AM
  • Hi Cubeslam,

    Regarding the performance you're seeing with the Tiled Resources sample, as Rob mentions this is due to the sample explicitly using the software renderer as a fallback in the absence of hardware support for the feature.  There are numerous alternative techniques to rendering high-detail objects that run on min-spec Windows machines, but illustrating those was not the purpose of the sample.

    I am curious, though - for future DirectX samples that require specialized hardware, if hardware is not available on the machine, would you prefer to see the sample run correctly, but slowly, on the software rasterizer?  Or would you prefer to see an error message indicating hardware support is not available?  Perhaps a combination?

    -Matt

    Thursday, August 15, 2013 10:34 PM
  • Hi Matt,

    since I had to go for similar features on work, I looked myself into diverse techniques for very low-spec machines, and am starting to get very efficient results. Regarding the future samples, I suppose slow is better than nothing, only that the user should be notified in some sort that his system limits the capabilities. So yeah, I'd go for a combination personnaly, at least to be aware of why it runs slow.

    Personnal opinion on that one too, it would be interesting to provide a sample with an effective fallback that runs smoothly on low-spec machines, even if cpu bound. I know it's possible, but many devs might decide to put it aside on first glance if their rigs can't use it correctly.

    Thanks

    Thursday, August 15, 2013 11:13 PM