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.
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.
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.