Greg Schechter: Windows Presentation Foundation(WPF) Architecture | Going Deep

prog_dotnet

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 Smiley

raptor3676

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

prencher

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.

prencher

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?

PerfectPhase
"This is not war, this is pest control!" - Dalek to Cyberman

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

staceyw
Before C# there was darkness...

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