From the DX level, WPF rendering Caton

It's not a blog down to the bottom , A lot of details DX The ground floor is related

All my friends know stay WPF It uses DX As the rendering of the bottom layer , Talking about WPF When you're stuck , Please don't forget dx Part of it is possible that there is a carton

stay WPF Of OnRender After method call , Will make dx What do you do ？ At this time WPF It will complete the collection of frame drawing commands for the complete frame , At this time, too dx The completion of the frame drawing command of the complete frame . then dx These drawing commands will be passed to UMD (User Mode Driver) layer

The above sentence is only a single one UI Thread time takes effect , If more is used UI Threads will be more complex , This article also does not discuss much UI Threads

And in the WPF Of OnRender After method completion , In fact, it just passes the frame drawing command to UMD Not on the screen

stay UMD Is responsible for converting the collected drawing commands to GPU Working batch that can be handled , That is to say work batches And command buffer （Display Lists） According to the corresponding hardware GPU Convert to different instructions . This part is relatively complicated , Please see the official document for details

stay UMD When it's done , The command buffer will be passed back to D3D Let it give the command to the context queue , and KMD（ kernel mode GPU driver） The layer draws according to the command , Details please see GPU Rendering Pipeline——GPU Introduction to rendering pipeline - You know

After the painting is finished, it will be in GPU A complete image is drawn in the cache , And it's still not on the screen , Need to wait Present Command will make the screen output

Through the above, , Of course you need to read the additional blog , If WPF Of OnRender It's stuck , No draw command is output to DX It will delay the frame drawing command of the whole frame , This part is on the user code , It's better to debug

The second part is to convert the collected drawing commands into corresponding drawing instructions , This part is related to specific equipment , If you give some toxic paint , Then the conversion time will be longer . In other words, the driver takes longer than expected to be GPU Get ready for a frame that needs to be rendered , This part will be in win7 Handoff dpi When it doesn't restart , Part of the hardware equipment reappears

The third part is that although my drawing commands are few , But this drawing command is a big Geometry , It happens that this geometric treatment is GPU There is no optimized , that GPU It needs to be used for a long time . This part of GPU Devices are rarely encountered by high-end users , But I happen to be developing applications for a lot of old devices , It means I'm using PathGeometry We need to pay attention to the size of the geometry

And according to the vertical refresh , Just miss the frame , Will not output until the next painting . That's delay 1ms - 8ms Basically the same for latency , That is to say, one time can optimize , At least it needs to be optimized over 8ms Otherwise, it has little effect

What's inserted here is Windows The system is not just one application for drawing , That is, there are a lot of CPU When , Will make GPU The running of the working thread of is interrupted frequently , There are a lot of thread changes in one rendering process . let me put it another way , A high performance UI The framework is not that more threads are better . Please look at this part DirectX Multithreaded rendering performance related

A piece of article introduction DirectX 12 - You know

Commit command buffer - Windows drivers

GPU Rendering Pipeline——GPU Introduction to rendering pipeline - You know

The information in this article is more intensive , All I can say is a general idea , For more information, please see the links cited in this article , Especially official documents

I think what I write is only the notes of official documents , The only thing that works is with WPF The associated

stay WPF in , from dx The following is the suggested order of the carton debugging

• stay OnRender The execution time and frequency of , adopt ContentRender The frequency of events can be obtained . But this event is only used for debugging , Listening for this event at the same time will reduce rendering performance
• stay WPF It uses complex text or geometry
• Whether in WPF A lot of UI Threads

in addition , There is one caveat , When debugging rendering performance , Debugging itself will affect carton . In other words, it's not accurate to use debugging method to measure where the Caton is , It's basically slow in rendering a carton 1ms It's katon , And fast 7ms Not optimized yet

If I don't find WPF Layer problem , And want to know if dx The rendering of carton , You can try to use Fraps Tools

I set up my own blog https://blog.lindexi.com/ Welcome to , There are a lot of new blogs in it .

If you see anything in the blog that you don't understand , Welcome to exchange , I built it. dotnet Vocational and technical college Welcome aboard

This work adopts the signature of knowledge sharing - Noncommercial use - Share in the same way 4.0 International license agreement to license . Welcome to reprint 、 Use 、 Re release , But be sure to keep the article signed by Lin Dexi , Not for commercial purposes , Based on this revised work must be released with the same license . If you have any questions , Please contact me .