Joe Wood's Blog

I was impressed with Nathan's reflective textbox in Avalon.  I wanted to improve on his sample and make the reflection 3D.   The same opacity gradient applies, but this time the VisualBrush is used on a material on a 3D surface.  The 3D surface also needs to align itself underneath the TextBox.

Download the project and binary here.

The big 'gotcha' with the Beta1 RC of Avalon is that VisualBrush doesn't work on 3D surfaces unless it is rendered in 2D first.  The workaround is included in the sample to make sure the TextBox can be used as a material.

I will convert the sample to a re-usable Style.  I'm interested in how far I can push using Styles without resorting to custom controls.  Maybe this could become a generic style that reflects anything in 3D.  I would also like to make the reflection include a visual blur, maybe overlay an alpha-channel texture with the VisualBrush.

Also, the sample is plagued with another problem : - in Avalon, at the moment, using any sort of 3D texture causes the CPU to max out at 100%.  The responsiveness of the TextBox is noticeably slower than a 2D only one.  Hopefully this will be resolved soon. 

A little while ago, I came up against some performance problems in a mixed Managed/Unmanaged C++ assembly.  I decided to profile the code and found that it wasn't as I had expected.  The functions in unmanaged code, and even the functions from a vendor C++ API, were all appearing as managed .NET functions. 

The C++ assembly had some managed classes (marked with '__gc') and some non-managed classes (marked with '__nogc').  My assumption was that the 'It Just Works' marsahling between managed and unmanaged code was working between the '__gc' and '__nogc' classes.  The non-managed code included some virtual function overrides, overriding functions from a vendor library..  According to the profiler (and Reflector) even this function was a managed function and was included in the meta-data in the assembly.  I could even decode the function and see the disassembly in C# !

So, after digging around the internet I discovered that the __gc and __nogc prefixes didn't work as I had expected.  These directives actually apply to the data and not the code.  If a class is marked as __gc then this means that the data type is collectible by the garbage collector.  It has no impact on the generated code inside the class.  If a class is marked as __nogc then the data is native, but the code inside the class is still IL code.  This means that all the code included from external header files (inside inline functions etc) is all MSIL.  The virtual function that I was running as part of the vendor library was going through a number of unmanaged to managed transitions, although no data was being marshaled across the boundary, this still took time and was impacting the overall speed of the application.

The solution is to tell the compiler to generate native code, instead of MSIL.  This can be done using the '#pragma managed' and '#pragma unmanaged' directives.  So, in simple terms, interaction with the vendor library should look like this:

To call out of the unmanaged code into the managed code the unmanaged class can hold a reference to a managed type using the template class gcroot<>.   You can also include specific managed functions in unmanaged types.  It's interesting to notice that if any unmanaged class has any MSIL based functions then the class name is included in the meta-data in the assembly. 

It's all very nice, with the channel 9 video and blog entry, using RSS as a standard method to do polymorphic vector persistence is a nice touch.  Here are some observations on the video:

First off, before everyone gets excited about 'RSS for the masses' and using a subscription model will be the 'new standard way of browsing the web'.  It's worth thinking back to around 1996 when IE and Netscape were rushing the 'push' model to the market.  Back then it was called 'channel subscriptions' but it never really caught on.  I think this will be more successful, but it's worth keeping in mind why the 'channel push' didn't work last time round for the average user.  I blame lack of adoption, on demand connections and a general bad implemention on the user interface. 

The team kept mentioning that the 'glue applications' that they used to pull together these feeds were all written in C#.  I think we can assume that this RSSimplement ion toolkit is going to be a .NET assembly.  I won't be the only one hoping that this means that IE7 will *depend* on .NET 2.0.  This will make the download huge of course, but it makes perfect sense to pay this price now and make the download for WinFX runtime in the future less than 100MB. 

If you think about it, IE7 is the perfect deployment vehicle.  For the tech savvy, with broadband connections, the large download will not be a problem.  For the general public, who really don't care which version of IE they have, will get their version through the mail from their ISP or on a cover disk on a magazine. 

For the .NET world the lack of installed base is a big issue.  With users taking a long time to upgrade their OS, Longhorn is too far out.  Given that Avalon and Indigo are based on the same runtime as Whidbey, which is being released in November, it makes a lot of sense to get this version on as many desktops as possible.