Pigs Can Fly : Beyond Hello World

Beyond Hello World - Update 5, TreeMap Control Working, Perf Issues

rgr — Sat, 24 Mar 2007 21:03:00 GMT

CLCV V5 now has a fully working TreeMap control that zooms, supports mouse over events and looks pretty good. The regions are laid out with the Squarified TreeMap algorithm. Even better, the tree map itself scales to large numbers of nodes - easily 100's of thousands, and on my lap top, it will handle a couple of million nodes relatively well. But there are two major performance problems: 1) WPF rendering seems to be very expensive. 2) Tree Map nodes are relatively expensive in terms of memory size. This limits the number of nodes to a ~2 million. You can find a link to the source code at the end of this post.

Note - all performance numbers (number of objects, times and profile data) are gathered from my new Acer Ferrari 5000 laptop.

From a memory usage perspective the control performs acceptably for even a few hundred thousand nodes. Tens of thousands of nodes are no problem. But, it does begin to struggle with about a million, with two million being a empirical limit. A future post on this WPF version of CLCV will focus on memory optimizations and usage in detail.

For this post, I'll focus on WPF rendering performance. In summary, the primary performance issue that limits the scaling of my treemap control isn't memory or CPU time to compute or render the layout - it is actual physical rendering of the rectangles and text by WPF itself. WPF cannot keep up with more than about 750 rectangles and a small number of scaled text items.

My treemap control is pretty well optimized (there is still some work to do) - but the computational performance of the control itself is not the limiting factor. The most important aspect of my treemap implementation is that it is smart about how much work it does -limiting its computations and rendering to only the nods that are reasonably large.

When learning about treemaps, I looked at some existing code and read all the web material I could find. It looks like most implementations are pretty basic - they compute the size and location of each rectangle for the entire tree. I thought this was a bit odd. It seemed to me that it would be more efficient to only process the part of the tree that would be visible - e.g. computing and rendering tiny or invisible rectangles didn't seem like a good design decision to me.

My first implementation took the straight forward approach as well. As I suspected, for larger trees - even those with a only a few thousands nodes, computing and rendering tiny rectangles was a waste of computation and rendering time. As you can see in the image to the right, rectangles that are smaller than some limit are too small to effectively mouse over or to meaningfully discern their relative area with respect to their parent.

So, I modified both the layout code and the rendering code to stop when the area of the rectangles became less than some threshold. This worked very well both from a visual perspective and performance standpoint. It also allows the data tree to become very large as it means that neither the layout and rendering costs grow with the overall tree size as the number of nodes surpasses the number of rectangles that the algorithm decides to actually render.

Experiment: CLC V5 includes a unit test for the treemap control that allows you to control the size of the three and set the treemap parameters such as the Area Limit.

The area limit is the minimum size of the rectangles that will be rendered. Assuming there are enough nodes, the larger this number, the fewer rectangles will be visible.

From empirical testing I determined that a value of 64 works pretty well.

For trees over a one or two thousand nodes, there are usually more nodes than can be displayed. In these scenarios, the scaling limitations are inherent to WPF itself, not the layout computations, or rendering in the treemap control.

Its important to understand how the control works and when WPF actually does the visible rendering. The treemap control has two main steps: the first is the actual layout computations of the tree, and the second is the rendering of the tree. Once the control is rendered, then WPF will take the rendering data generated in the control's OnRender function and actually turn that into DirectX commands that become visible on the screen. Its this third step that is the limiting factor.

The layout computations are handled by a function called ComputeAllNodeBoundingRects. This function starts at the root node and recursively computes the size of each visible rectangle for the nodes in the tree. This function stops its recursion when it reaches nodes that have visible areas less than the Area Limit. You can experiment with area limit values using the unit test (see above). If you set the area limit to zero, then the layout computations will compute a rectangle for every node in the tree.

Computing the bounding rectangles only needs to happen when the treemap control receives a new data tree (by setting the TreeMapData property), or when the render size changes (handled by the OnRenderSizeChanged event).

When WPF determines that a control needs to be rendered, it calls the controls OnRender method. This control's OnRender method recursively paints each of the rectangles computed in ComputeAllNodeBoundingRects. It also renders the text for the root nodes and first level nodes.

Both of these functions are relatively fast - here are some statistics for the initial random tree. LQ means 'lower quartile', UQ means 'upper quartile', IQ range is the inter quartile range divided by the median value. Range is the total range (max-min) divided by the median. Times are in milliseconds.

	Count	Min	LQ	Median	Mean	UQ	Max	IQ Range %	Range %
Compute	100	2.6	2.8	3.0	3.4	3.4	7.7	18.4%	171.7%
Render	100	5.8	6.2	6.7	7.3	7.7	19.6	21.8%	204.9%

These times are for computing and rendering from 1,316 to 1,539 visible nodes. As you can see from the times, neither compute nor rendering times in the control itself should inhibit the control from rendering smoothly. This is especially true when the control is rendering due to events other than size changes.

But, even with the times above, the control still struggles to render - you can see this by just rolling the mouse over the control and watching the lagging mouse-over node changes, or by resizing the control. In both cases, if the control is painting more than 700 rectangles or so, then it can't keep up.

While relatively anecdotal, the CPU utilization for the control also seems on the high side. Just continually moving the mouse over the control uses considerable CPU, 70 to 80%. This is high, especially considering that my lap top has a dual core AMD Turion processor with has a WinEI rating of 4.8.

While there does seem to be some material performance and scaling issues with WPF, there is a lot to like about the programming model. I'll talk about this more in subsequent posts.

Source Code for this post: CLCV-BLOG-5.ZIP contains the source code to this post. I didn't include the data files in this zip file as they haven't changed - you can simply use the ones from CLCV-BLOG-3.ZIP.

Beyond Hello World - Update 3, Control Templates, Multithreading, and more... (with source)

rgr — Mon, 22 Jan 2007 04:58:00 GMT

I've learned a lot in working on my first real WPF application such as implimenting multi-threaded file reading, how to use the dispatcher object, how to use control templates to customize controls, the basics of application configuration, using abstract C# classes, and using anonymous methods.

I've posted the source code that goes along with this post. It is in the file CLCV-Blog-3.ZIP at the end of this post. This version of CLCV has some new features

It has an option dialog box for setting the user's preferences. This mechanism uses the application properties wizard in Visual Studio - this was surprisingly easy to do, but it does have one problem; I can't control where the data is saved! (yet).
File I/O is multi-threaded. One thread reads the lines from the CSV input file and sends the resulting data to the UI thread using the UI's Dispatcher.
File reading can be quickly canceled - an important attribute for a program that is designed to load large files.
CLCV displays an accurate progress bar as it loads the file.
The recently used file list now works correctly

It discards files that no longer exist when CLCV starts
It keeps the list sorted in order of use (most recent at the top).

There are many new concepts for a native C++ developer to learn when ramping up on WPF and C#. One of the most important is how to customize the look and feel of your applications - this is a Raison D’être for WPF. In my earlier versions of CLCV, I couldn't figure out how to customize the look and feel of buttons so I rolled my own using a rectangle and some animations. It looked ok, but this was completely the wrong way to go about it.

One of my friends (Joe Laughlin) pointed me in the right direction: Customizing controls is easily done using Control Templates which are designed to do exactly what I needed: completely controling the look and feel of any WPF control while maintaining their semantics. Even better, with WPF resources, this can be asily done for an entire application. Control templates made it stright foreward for me to set the look and feel of buttons in my application to a blue colored theme. So far, I've just scratched the surface of control templates, but you can see what I did by looking in resources\button.xaml. It is tied into the application in App.xaml like this:

    <Application.Resources>
        <ResourceDictionary>
            <ResourceDictionary.MergedDictionaries>
                <ResourceDictionary Source="Resources\Button.xaml" />
            </ResourceDictionary.MergedDictionaries>
        </ResourceDictionary>
    </Application.Resources>

The XAML above applies my customized Button control template to every button in the application without touching the XAML for the other windows or pages. This is very cool. More than cool, its a great example of how WPF separates design (look and feel) from an application's semantics.

An important feature of CLCV V3 is its options dialog box. This makes it easy to tweak and tune key parameters without recompiling. Here is some info on the options:

Show Console: when checked, CLCV will display its debug/diagnostic console.
Synchronous Line Reads: this forces the file reader thread to post messages to the UI thread synchronously using Invoke() instead of BeginInvoke(). ( using Invoke()this is slow)
Animate Directory Loading: when checked, this forces CLCV to visibly populate the tree view control as items are read (this is slow).
Maximum Outstanding Messages: this is the maximum number of outstanding messages the file reader thread will have with the UI thread.
Message priority: this is the DispatcherPriority used by the reader thread send messages to the UI thread (in the calls to Invoke() or BeginInvoke().

While V3 of CLCV is still naively implemented in many regards (this is my first WPF app and I only started with C# and WPF in late December '06). But, I knew from the get go that I'd have to handle file reading in a thread separate from the UI thread to avoid UI hangs and sluggishness during file loading.

Of course, it is possible for single threaded applications to efficiently read files and keep their UI responsive - I have a native C++ class that provides I/O support for this. My native class is extremely efficient and can easily drive the disk at its maximum sequential read rate with one thread. But, this is more complex in .NET 3.0. While .NET does provide the fundamental support for asynchronous I/O, I'd essentially have to re-implement my Native C++ classes in C# and I'm not ready for that yet.

This approach would also be just as messy in WPF as it would be in native code: mixing I/O and procssing UI events in one thread requires a state machine approach to handle issuing asynchronous reads, processing UI messages, and handling completed read events. This is prone to complexity and can be difficult to debug and maintain.

Fortunately, it is very easy to create a file reading thread in .NET and for that thread to send its data to the UI thread asynchronously. It takes surprisingly little code to do this:

   1:          public FileLoader( DataViewWindowClass dvw )

   2:          {

   3:              MyDataViewWindow = dvw;

4:

   5:              UseSyncronousLineReads      = TheApp.UserProperties.SyncronousLineReadsFlag;

6:

   7:              StartFileLoadHandler       += MyDataViewWindow.StartFileLoad;

   8:              NewFileHandler             += MyDataViewWindow.AddNewFileHandler;

   9:              NewDirHandler              += MyDataViewWindow.AddNewDirHandler;

  10:              NewDirTreeHandler          += MyDataViewWindow.AddNewDirTreeHandler;

  11:              FileCompletedSignalHandler += MyDataViewWindow.FileCompletedSignal;

12:

  13:              FileLoaderThreadEntryPoint  = new ThreadStart( LoaderThread );

  14:              MyThread                    = new Thread( FileLoaderThreadEntryPoint );

  15:              WaterMarkSemaphore          = new Semaphore( TheApp.UserProperties.MaxOutstandingMessageCount,

  16:                                                           TheApp.UserProperties.MaxOutstandingMessageCount );

  17:          }

The code above is from DataView.Xaml.cs. It creates the FileLoader object which owns the file reading thread. The reading thread uses five delegates to communicate with the UI thread:

One to signal that the file loading operation has actually started. This message is used to send the file size to the UI thread so it can setup the progress bar.
One message each for for files, directories, and directory trees. Each of these messages also includes the number of bytes read from the file so far. This allows the UI thread to keep the progress bar up to date.
And finally, one to signal that the file read is completed.

The reading thread does all the work to read the file, which is in comma separated value (CSV) format. The CSV file contains all the data necessary for CLCV to reconstruct the directory tree scanned by CLC. (note, in the TestData directroy from ZIP file, I've included three CSV files, one small, one medium sized, and one large - this is actual data from some of my source code trees).

The reader thread handles the following work

file reads using a StreamReader object
detecting header lines and blank lines
splitting each line into the comma separated fields
parsing and converting the text data to binary data and putting that data in objects
sending those objects to the UI thread

All in all, this works quite well for a first attempt: the UI stays alive (doesn't hang), the file read operation can be quickly canceled, and its all done with straight forward code.

Note that getting the dispatch priority correct is very important. On a single CPU system (like my laptop), using too low a priority simply causes the entire process to drag out. Using too high a priority causes the I/O thread to starve the UI thread. For example, if you set the dispatch priority to "input", then the UI thread may need to work through large numbers of input messages before it processes input events, such as a cancel request. Setting the dispatch priroity above "input" (to "loaded" or "render") will keep input events from being processed.

Going higher, to "render" will interfere with the actual rendering of the UI causing the progress bar to be jerky. Going higher than "render" to "databind", "normal", or "send" completly stops UI rendering and blocks all input thus hanging the UI; this is specific problem that multi-threaded I/O is intended to handle.

The "Background" dispatch priority seems to work acceptably well. Using this priority, the UI remains responsive while consuming input events fromt the reader thread relativly smoothly.

Note that using dispatcher priorities is orthogonal to setting thread priorities - the dispatcher priority is simply the priority at which the dispatcher removes input events (delegates) from its input queues.

But, there are some performance issues in this initial naive implementation:

The progress bar doesn't terminate nicely - it gets updated to 100% complete in the UI file completion routine (see the function FileCompletedSignal() ), but WPF spends a lot of time in this function before it re-renders the UI. I need to figure this out.
The biggest problem is the time it takes to actually build set of tree view items that are used to populate the list of directories and files. This takes 10 to 20 times more than the actual file I/O, which is very surprising given that in native code, I have tools that do significantly more text processing while still remaining I/O bound - all in one thread.

The performance of the tree view control itself also bogs down with the largest file. Its noticeably sluggish when the selection changes.

That being said, my first implimention is certainly naive - I simply build a set of tree view items that mirror the entire file and directory structure. It doesn't look like too much trouble be a lot smarter about this - populating the tree view as needed from another data structure. I'm going to try this next.

In upcoming posts, I'll explore better ways to handle the TreeView control (only populating it as necessary), do some profiling to see if I can speed up data processing, and add some more advanced control templates, and explain why its important to throttle the number of messages from the file reading thread (a producer) to the UI thread (the consumer).

Beyond Hello World - An Update On My First WPF Application (with source)

rgr — Thu, 04 Jan 2007 02:28:00 GMT

I've been working on my first useful WPF application and I've learned several things since my last post and answered a few questions. I've included a ZIP file with my updated source (you can find it at the bottom of the post, it includes full Visual Studio 2005 project) Here is what I've leaned:

How to create wrapper functions for native Win32 interfaces.
How to create a console window and direct the output to the Trace and Debug classes to the console window.
How to create an animated button using a rectangle, styles, and a storyboard - all in XAML.
How to close a WPF Window object.

(1) Of course it is possible to write a WPF or managed application without calling Win32 APIs. But that can sometimes be limiting as there is functionality provided by the Win32 APIs that are not available via .NET classes. The WIn32 console classes are a good example: .NET provides the Console class, but no methods for actually creating or manipulating the console window itself.

I knew from talking to others that calling native API's should be easy and I found a few examples of this using marshaling.   However, the examples didn't work for some of the APIs I needed.   So, I emailed the internal .NET development alias with a couple of questions. It turns out that calling native Win32 APIs is really, really easy - much easier than some of the examples on the web. You can see how to do this in the Win32API.CS file.

Here are a few things to note in this file:

There are no explicit marshaling statements.  When declared correctly, the C# compiler generate the interfaces correctly.

Note that the output parameters that need a pointer to a structure are simply declared using the 'ref' statement.   A .NET class would have worked here as well, but value objects (structs) seemed more appropriate.

You should use IntPtr as the type for handle - these are compatible with the safe handle classes.

Note the use of types like UInt32 and UInt16 which mirror the standard Win32 data types.

(2) I learned how to use the trace and debug classes with a console window from the application itself. CLCV now creates its own console window and uses the ConsoleTraceListener class to direct all the output to the Trace and Debug classes to the console window. This was a bit tricky as I needed to interface directly with some low level Win32 APIs.   To do this, I created two wrapper classes called K32 and U32. These classes provide the data structures and interfaces necessary to call into the Kernel32 and User32 DLLs respectively.

With these interfaces, its straight forward to create a console, open up the CONOUT$ handle to activate STDOUT, then set the size of the console window to 50 lines and 132 columns (the default is a bit small). This is really handy - it allows me to see the trace and debug output without using any other applications.

I'll update CLCV to make this console window optional in the future using a configuration dialog and possibly a hidden control.

(3) The WPF Button object is nice, but it controls its own behavior when it gets the focus - there is no way to control this. So, I decided I wanted a spiffier close button on my main window.   After about three hours of reading documentation and experimenting, I developed used a Rectangle object to build a nice close button with a mouse over animation. This was a little tricky because the Rectangle object doesn't support the IsMouse over property, it only supports MouseEnter and MouseLeve. This mean I needed to animate both events.

The outcome was pretty nice even though I'm a pretty poor UI designer (check it out!)

(4) Doh! Sometimes things are so simple. The code in the previous post simply used the red X button in the window frame to close the app because I couldn't find the event or message to close the window.   I was trying too hard!   Closing a WPF window object is trivially easy - just call its Close() method.

I continue to be surprised with how easy many things are with WPF and .NET. For example, the animated close button would require large amounts of relatively complex code in C++. With WPF, the animation itself took zero C# code and 33 lines of simple XAML code. With even a basic understanding of XAML (which is what I currently have), the code for the button is straight forward and easy to understand. I believe that anyone who is proficient in HTML could understand what is happening without know XMAL.

I'm really starting to see how XAML is a great bridge between designers and developers - while it can be complex, its straight forward enough to be understood by people who are not developers.

Of course, all this simplicity comes at a price - the XAML and .NET run times are not free - they can have significantly more computational overhead and memory usage than native code. That being said, it seems like a reasonable price to pay for many types of applications and (like many technologies) they will get more efficient over time.

Notes on the source code

This update includeI some very nicely implemented class from Sven Groot (Ookii.org) that make it easy to use the Vista style common file dialogs for .NET 2.0 (version 1.2). You can get the full package here.
I've included a "testdata" directory along with the source code that contains empty files. Thiles files all have the ".clc.csv" suffix. This is what the CLCV applicatoin looks for.

Beyond Hello World - My First WPF Application (with source)

rgr — Sat, 30 Dec 2006 23:49:00 GMT

My pet project for the holiday vacation has been writing a WPF application to view data from my code line counting tool CLC.EXE (soon to be released on Codeplex). CLC produces counts of lines, code, comments, and other statistics per file, per directory and for entire directory trees. When complete, the CLC data viewer (CLCV) will read a CLC data file and display various visualizations of the data such as a tree map (see also, and also), some pie charts and perhaps a histogram or two.

I’ve included the first working CLCV application shell in the attached zip file. This project builds in Visual Studio 2005 (any version). I used Microsoft Expression Blend to design the UI. The app-shell currently implements the application’s initial UI panel which gives the user the opportunity to open a new file, or select a recently opened file. This panel has the following features:

It keeps track of the most recently opened files, keeping the sorted with the most recently opened file at the top. It also manages the list

When CLCV starts, it deletes any files from the list that no longer exist
When the user clicks on a file name that no longer exists, the name is removed from the list and the user is notified with a simple message box.

It uses XML serialization to save the recently opened file list.
It saves the recent file list in the users application data directory (not under My Documents)
When running on Windows Vista, it uses the new file open dialog box.

Note, to do this I used a really nicely implemented class from Sven Groot (Ookii.org). See his Vista style common file dialogs for .NET 2.0 (version 1.2) here.

I still have few things to do for CLCV’s initial UI panel:

The main UI needs a close button, but I haven’t yet figured out how to close a WPF window.
The main UI panel needs to remember its position – currently it always appears in the center of the screen.
For native applications, I usually create a console window for simple debug spew, but this doesn’t seem like the “.Net Way”. I need to figure out how to effectively use the Debug and Trace classes. For example, how do I get the debug and trace output when I’m not running the tool under the VS debugger?

This is my very first foray with both WPF and C#. My only material exposure to managed code has been some utilities written in managed C++ so I could use the excellent Dundas Charting products. I used managed C++ because I was in a hurry and needed to leverage my existing class libraries (this worked well).

So I was pleasantly surprised that getting the UI shell and initial UI panel up and running was astonishingly easy to do; especially given that I could barely spell WPF and C# a week ago. The most amazing thing to me is how little code was needed is to do all this; 161 lines of C# code and about 80 lines or so of XAML. This is probably at least an order of magnitude less code than it would take to do all this in native C++, even with a nice class library like WTL and ATL. Not only is it less code, it was also easy to do – the compile-test turnaround time is super fast and the VS environment and debugger has deep knowledge about the C# language and .NET class libraries. Intelisense is really helpful and saved me loads of timing having to go back and look at documentation. VS’s C# editor is also quite good at finding syntax errors without compiling, saving more time.

I'm sure that someone will point out that even doing this right on top of Win32 in C could be done in a small amount of code. I'm confident that is true in a limited way - but doing this with Win32, or even WTL/ATL would be a lot more code to get the same app behavior and features that are inherent in a C# and WPF application: the blended background, the nice use of fonts and colors, transparent controls, the nice use of animation to highlight focus, the flow and layout capabilities that let windows be resized and maintain a useable and attractive layout.

It took me about 15 minutes to develop a nice look and feel for the initial UI panel in Blend. There is simply no comparison here for native UI code - its all done by hand! The ability for UI designers to work efficiently with developers is a revolutionary capability.

There are other things I like about WPF and .NET as well:

The WPF controls, their properties, methods, and events, seem much consistent and coherent than those from Windows.Forms.
Microsoft Expression Blend is really easy to use and looks like it will be a great tool even at V1.0.
If you use Blend to start Visual Studio, they work nicely together.
I like Intelisense with native and managed C++, but wow, it sure is awesome with C# - the editor and dev environment know WAY more about C# than they do C++.
I really like how well the XAML code and the C# partial classes fit together: The C# code can simply reference objects defined in XAML by their name which is defined by the “x:key” attribute.

I did run into a few issues though:

Blend is a memory HOG. My system has 1GB of memory and running dev studio and blend together often cause a lot of paging.

The idea behind XAML is great, but I think the implementation in XML is clunky. It seems that every new thing at Microsoft uses XML. Is that always the right choice? Does a having a good hammer make every problem a nail?
Data binding is still confusing to me…. It sure seems complicated, but I suspect that I just need to work on groking it…
There is a TON of documentation on WPF, .NET 3.0 etc, but I still find it difficult to figure out how to do simple things.

For example, I needed a simple way to save and restore the recently used file list. The .NET Configuration class seemed like a good place to start. I spent about two hours dorking around with the Configuration” class before I gave up. It and its related classes are way too complicated and the examples were SuperCrapy™. So, I tried XML serialization. It took me about 15 minutes to get the save and restore functionality working – nice… J
There seems to be a lot of name space overlap between .NET 3.0 (WPF) and Windows.Forms. Of course, this is why we have namespaces! But, the MSDN docs don’t really make it clear at the top level what is what – everything is under the class library hierarchy.

Glork! Why in the heck do the .NET classes not support the new vista dialog boxes??? While Sven Groot’s classes are really handy (and nicely implemented), I shouldn’t have had to use them. Am I missing something? Is Sven missing something? Perhaps so…

It is important to note that the benefits of WPF, C#, and managed code in general come with costs. These applications are by their very nature larger in terms of memory and CPU utilization. Our experience on the client performance team is that it takes a lot of work to ensure that a managed application launches quickly, remains responsive to user interactions, performs well in terms of throughput, scales well to large data sets, and is a "good citizen" in terms if system resource utilization.

Good performance for managed applications is certainly possible, but developers need to be aware of the costs associated with managed applications, design for performance up front, and use performance tools (such as logging and profiling) to maintain good performance during the development process.