dotnet
Enhancement of RenderTargetBitmap to Support Hardware Rendering
Fixes #9021
Description
In WPF, RenderTargetBitmap (also RTB) currently only supports software rendering. This limitation leads to performance bottlenecks and causes ShaderEffect implementations to become ineffective. Enhancing RTB to support hardware rendering would provide significant performance improvements and enable high-quality rendering features that are currently restricted. This limitation has been extensively discussed in the past (#144, Add optional hardware acceleration to RenderTargetBitmap and some website was lost: RenderTargetBitmap and Hardware WPF Rendering).
As a developer who is proficient in graphics and C#, one of my requirements is to export WPF-rendered UI as video efficiently. Current methods such as using BitmapCache (which cannot retrieve content back to memory) and hooking DirectX APIs (which is complex and unstable) are not feasible solutions.
Customer Impact
RenderTargetBitmap will only support software rendering and may experience performance bottlenecks as well as ShaderEffect not working as expected.
Regression
No
Testing
Additional tests may need to be added to verify that it behaves correctly with different drivers (no graphics, integrated graphics, discrete graphics) and in the event of missing devices, etc. May also need to check for potential memory leaks.
Risk
Due to API changes, PixelFormats.Prgba128Float will no longer be supported when creating a RenderTargetBitmap.
Although code can fall back to software when no hardware device context is acquired, this needs to be extensively verified. May also need to check for potential memory leaks.
This is a huge change, but I think it deserves to be discussed in depth and considered carefully!
Microsoft Reviewers: Open in CodeFlow
Hello every reviewers, I was wondering if there's any update on this PR? @singhashish-wpf @dipeshmsft I tagged you as you seem to be the expert in this area and I'm a bit lost on how to proceed. My apologies if I'm out of line.
Hello every reviewers, I was wondering if there's any update on this PR? @singhashish-wpf @dipeshmsft I tagged you as you seem to be the expert in this area and I'm a bit lost on how to proceed. My apologies if I'm out of line.
Pretty sure this PR will be on hold for yet another several months before it finally gets reviewed and merged just like any other community PR which touches some fundamental things.
Hello every reviewers, I was wondering if there's any update on this PR? @singhashish-wpf @dipeshmsft I tagged you as you seem to be the expert in this area and I'm a bit lost on how to proceed. My apologies if I'm out of line.
Pretty sure this PR will be on hold for yet another several months before it finally gets reviewed and merged just like any other community PR which touches some fundamental things.
Thanks for your reply, waiting for good news!
Current methods such as using BitmapCache (which cannot retrieve content back to memory)
As I have mentioned above: BitmapCache cannot retrieve it's content back to memory. It only stays in GPU memory. If you try to use BitmapCacheBrush and draw it to a DrawingContext then renders it to a RenderTargetBitmap, it still fallbacks to CPU render.
The only way you can "capture" a Visual into a CPU accessable memory is to use RenderTargetBitmap. This will inevitably result in all the content on it being rendered using the CPU. As proof, you can add a GPU only DX shader on Visual as ShaderEffect, and I guarantee it won't take effect.