(*Desktop Silverlight for Windows)There haven’t been too many articles written about the rendering subsystems of WPF and Silverlight, at least not in great detail. This leaves room for quite a bit of speculation and leads to some turf war augments between some Silverlight and WPF developers. I want to document (brain barf) at least what I have gathered from qualified sources, observations, educated guesses and plain old snooping around public symbols. I did not acquire knowledge of any of this under NDA and I cannot guarantee all information here is accurate, so I encourage others to let me know what is incorrect. Windows Presentation Foundation
A Brief HistoryThe first version of WPF was RTM’d around the time of Vista and was included in .NET 3.0. It touted a fully GPU accelerated user interface. The native-code part of WPF was called the “milcore”, also known as the “Media Integration Layer”. This part of the code was shared with the Vista DWM (aka Aero). Since .NET 3.5(sp1?), WPF’s “milcore” and the Vista DWM had split off. Presumably because major and possibly breaking changes had to be made to WPF’s native rendering stack (e.g., pixel shaders). With Windows 7, the DWM has moved on to Direct3D 10 and WPF 3.5 and 4 are still using Direct3D9 (9Ex on Vista and higher) so there is little or no relation to the DWM and WPF’s native rendering stack.If you have ever peeked at the managed shared source code for WPF, you will find a lot of references to “DUCE”. DUCE stands for “Dynamic Unified Composition Engine”. From here on out I’ll refer to WPF’s rendering stack as DUCE…hopefully that is correct. Rendering Stack FeaturesFull GPU Acceleration – Unfortunately the term hardware acceleration has become generic marketing lingo. It is very important to ask “What is being accelerated and how?” For instance, there was a Flash 10 update that came around that enabled “Hardware accelerated video”. What was accelerated? Did it decode the video in the GPU then render it (and I found some believed)? Nope. It just used the GPU to scale video playback so your CPU didn’t have to run a scaling algorithm on every frame...when in full screen mode. So again, what is GPU accelerated in WPF? Well, just about every pixel you see is generated and composed by the GPU, with a few minor exceptions. My best guess how DUCE renders WPF visuals, colors, gradients is with shaders. Consider each shader to be a simple CPU core. Today’s low end GPUs have a couple hundred, while some high ends there are 700+! This allows WPF to have complex animations, while maintaining high frame rates at relatively low CPU usage. What I felt gave the DUCE performance a bad name in the early days was twofold. Low-end GPUs were still wide spread and there was no cached composition API that is in 4.0. Read more: Jeremiah Morrill
A Brief HistoryThe first version of WPF was RTM’d around the time of Vista and was included in .NET 3.0. It touted a fully GPU accelerated user interface. The native-code part of WPF was called the “milcore”, also known as the “Media Integration Layer”. This part of the code was shared with the Vista DWM (aka Aero). Since .NET 3.5(sp1?), WPF’s “milcore” and the Vista DWM had split off. Presumably because major and possibly breaking changes had to be made to WPF’s native rendering stack (e.g., pixel shaders). With Windows 7, the DWM has moved on to Direct3D 10 and WPF 3.5 and 4 are still using Direct3D9 (9Ex on Vista and higher) so there is little or no relation to the DWM and WPF’s native rendering stack.If you have ever peeked at the managed shared source code for WPF, you will find a lot of references to “DUCE”. DUCE stands for “Dynamic Unified Composition Engine”. From here on out I’ll refer to WPF’s rendering stack as DUCE…hopefully that is correct. Rendering Stack FeaturesFull GPU Acceleration – Unfortunately the term hardware acceleration has become generic marketing lingo. It is very important to ask “What is being accelerated and how?” For instance, there was a Flash 10 update that came around that enabled “Hardware accelerated video”. What was accelerated? Did it decode the video in the GPU then render it (and I found some believed)? Nope. It just used the GPU to scale video playback so your CPU didn’t have to run a scaling algorithm on every frame...when in full screen mode. So again, what is GPU accelerated in WPF? Well, just about every pixel you see is generated and composed by the GPU, with a few minor exceptions. My best guess how DUCE renders WPF visuals, colors, gradients is with shaders. Consider each shader to be a simple CPU core. Today’s low end GPUs have a couple hundred, while some high ends there are 700+! This allows WPF to have complex animations, while maintaining high frame rates at relatively low CPU usage. What I felt gave the DUCE performance a bad name in the early days was twofold. Low-end GPUs were still wide spread and there was no cached composition API that is in 4.0. Read more: Jeremiah Morrill
Posts
0 comments:
Post a Comment