When using a DirectX-based API with WPF (i.e. SlimDX, SharpDX, etc.) can you do sub-window-sized controls? -
in our wpf application, have need display 64 real-time level meters audio application. tests we've thrown @ wpf, when rendering basic primitives efficiently can still show near our application needs be, times bogging down main thread point it's non-responsive input.
as such, have go more optimized graphics performance such directx (via slimdx or sharpdx) or opengl/es (via atlas converts directx calls.)
my question if it's possible create multiple, small directx-based areas, each representing individual meter, or matter, right approach? under understanding have run @ minimum, entire window, not portion thereof.
the issues see latter airspace issues wherein can't have wpf content in front of directx content in same window, , don't want have redo of our controls in directx since other non-meter 95% of our ui wpf great!
i have read can render directx brush, use inside wpf, or using writeablebitmap class gives direct access buffers wpf uses in render thread, both of don't seem suffer airspace issues, seems we'd right @ same place wpf being bottleneck since still has rendering.
we of course going dedicate few weeks sample applications testing of above, i'm wondering if i'm headed in right direction, and/or if there caveats can avoid talking people experience doing avoid common pitfalls, etc. such, comments appreciated.
i'm hoping can perhaps start wiki somewhere discuss topic seems popular one, albeit spread on place making hard new entrants information seek.
with wpf / d3d interop, should try create smallest number of interop calls. should prefer rendering 64 level meters in single render target (also allows batch primitive rendering , draw in smallest number of gpu calls).
you should try use d3dimage api allows share own d3d texture wpf renderer.
Comments
Post a Comment