Greg Schechter: Windows Presentation Foundation(WPF) Architecture

watching it right now...so far very interesting..but I was a bit confused  in the beginning...had to do a live search to find out that Windodws Presentation Fundation is abbreviated WPF

 

Well I've got a couple of questions about the main threads of WPF.

First of all, there are 2 trees running by separate threads: the UI thread and the Rendering Thread.  The later thread, the rendering one, does it lives withing the program process or it does it within the desktop compositing process? which leads me to the second question.

If the rendering thread runs within WDM then, How all of these works on XP where there is no WDM whatsoever?


Atte:
Raptor

So if the rendering tree is different, and as he said in the video, it doesn't ask the widget to render itself each time but merely asks for its surface (pre-rendered), how does the widget know when to re-render?

Can it mark itself dirty so the next rendering pass requests a re-render, or does it just render whenever a change occurs?

The latter seems unrealistic, as that'd either mean rendering in your working thread, or having some way of calling into the render thread, both of which seem inefficient to me.

raptor3676 wrote:

Well I've got a couple of questions about the main threads of WPF.

First of all, there are 2 trees running by separate threads: the UI thread and the Rendering Thread.  The later thread, the rendering one, does it lives withing the program process or it does it within the desktop compositing process? which leads me to the second question.

If the rendering thread runs within WDM then, How all of these works on XP where there is no WDM whatsoever?


Atte:
Raptor

Theres a rendering thread per process, as well as in the WDM.
The WDM merely sees the windows as tree branches and requests a render from it (thats the point where it transfer into the process itself), which it then renders.

For non-avalon apps, theres a single tree entry - the GDI+ surface the window draws on.

For XP I suppose it just exposes a surface in the same way GDI+ does it, rather than a tree branch.

That was what I gathered anyway. Anybody care to conform this?

From watching the older vids, I always thought you guys call him Dr. Sneek.  Having read the intro it all makes more sense now 

Another great video in the Deep series Charles.

1) Interesting to find out console updates are bitmaps (Is that right?).  So every time you ouput to the console, GDI generates a new bitmap and invalidates the client area?

2) Would it be possible to use the same type of thing for console updates?  So only the "delta" changes are sent back over the wire to the client console?  Could that also be used to more easily produce "old school" console "block" UI like DOS Norton Commander, List, etc.?  That would be sweet to be able to open just a remote console to a server and be able to run any console program such as Edit (et al) and have it look right at the client (i.e. light-weight terminal server session).

3) Will this eventually replace the terminal server RDP protocol to just use the native WPF diff protocol over a remoting boundary?

TIA

Please, rename the title. It took me a long time to realize that WPF stands for "Windows Presentation Foundation".

Think about those who are not acronym savvy.

Great video.

Channel 9 I love you... as for your threads; not-so-much.

In my opinion a moderated /. style is alot nicer. For instance, you could moderate my posts as "Annoying".

-Deleted-

swright wrote:

In my opinion a moderated /. style is alot nicer. For instance, you could moderate my posts as "Annoying".

Hmm... A brand-spankin'-new user claiming to be annoying this fast.  Makes me wish I'd seen the posts that got deleted / edited. D'oh!

"Windows Presentation Foundation (WPF) Architecture" is the title. 
N/A

This was one of the best channel9 videos I've seen--both intelligent and interesting.  Very nice.  I would love to see more of these going deep ones.

A great video though a lot of what was said was familiar from the blogs already, for some more detail one can see the USPTO pub 20050140694, however I've yet to find what patents cover the video play^h^h^hrotection.

The impression I got from the video is that the DWM doesn't see the visual tree of a WPF app nor its "render tree" equivalent, but only gets the final rendered window contents via a shared surface (a feature of the WDDM) and that there is additional communication (within milcore?) between WPF and the DWM to coordinate stuff like scaling for the magnifier. On XP there is no DWM, so no need for this interaction.

Good video and worth the time.  It broke down what a channel was conceptually, which caused me a ton of confused.  Specifically, with regards to the general direction and goals the wdf team were out to address.

prencher wrote:

So if the rendering tree is different, and as he said in the video, it doesn't ask the widget to render itself each time but merely asks for its surface (pre-rendered), how does the widget know when to re-render?

Can it mark itself dirty so the next rendering pass requests a re-render, or does it just render whenever a change occurs?

Well you don't have to handle invalidates so you would only need to render when your client area actually changes.

prencher wrote:

So The latter seems unrealistic, as that'd either mean rendering in your working thread, or having some way of calling into the render thread, both of which seem inefficient to me.

He goes over what gets passed to the render thread in the video, and mentions that when the UI thread and render thread are in the same process shared memory is the mechanism these threads use for communication.

staceyw wrote:

Another great video in the Deep series Charles.

1) Interesting to find out console updates are bitmaps (Is that right?).  So every time you ouput to the console, GDI generates a new bitmap and invalidates the client area?

2) Would it be possible to use the same type of thing for console updates?  So only the "delta" changes are sent back over the wire to the client console?  Could that also be used to more easily produce "old school" console "block" UI like DOS Norton Commander, List, etc.?  That would be sweet to be able to open just a remote console to a server and be able to run any console program such as Edit (et al) and have it look right at the client (i.e. light-weight terminal server session).

I do think this type of app is kinda' cool, but you don't need to wait for WPF; use sockets and a telnet client.

Yep, prencher pretty much has it right in this comment. 

WPF applications each have their own render thread, and they render into a DirectX Surface.  This is true on XP and on Windows Vista.

On XP, the WPF apps display is just like any other DirectX applications display.  Just right to the desktop.

The Desktop Window Manager (DWM) basically is its own WPF application, and thus has a surface it renders to.  However, it gathers shared surfaces that GDI and DirectX applications themselves render to, and composites those as bitmaps to form the desktop.  (BTW, it's GDI surfaces, not GDI+ surfaces.)

BTW, I talk a fair bit about this general window redirection mechanism for the DWM in this blog posting.

Greg