Entries:
Comments:
Posts:

Loading User Information from Channel 9

Something went wrong getting user information from Channel 9

Latest Achievement:

Loading User Information from MSDN

Something went wrong getting user information from MSDN

Visual Studio Achievements

Latest Achievement:

Loading Visual Studio Achievements

Something went wrong getting the Visual Studio Achievements

Greg Schechter: Windows Presentation Foundation(WPF) Architecture

Download

Right click “Save as…”

How is WPF designed? How does it work? Join Charles, Tim Sneath (Dr. Sneath, to us on the C9 team) and WPF Architect Greg Schechter as we dig into the guts of WPF as well as discuss it's past and future.

Check out Greg's blog here.

Tag:

Follow the Discussion

  • 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

     

  • 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?
  • PerfectPhasePerfectPhase "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
  • William Staceystaceyw 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
  • KobiashviliKobiashvili Searching for the 'ANY' key

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

    Think about those who are not acronym savvy. Wink

    Great video.

  • CharlesCharles Welcome Change
    I changed the title based on your feedback.
    C
  • 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-
  • tsilbSlackmasterK This Space ​Intentional​ly Left Blank
    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!
  • William Staceystaceyw Before C# there was darkness...
    "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.

  • DCMonkeyDCMonkey What?!?
    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.
  • Big Smile 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
  • Christian Liensbergerlittleguru <3 Seattle

    Great video! Let us see more on WPF and WCF!!

Remove this comment

Remove this thread

close

Comments Closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums,
or Contact Us and let us know.