Pointers, of course, are a way of life in C/C++. They have their aggravations, but it is virtually impossible to code anything performance-related without them. So, you get pretty used to them in those languages.

Along comes C#, with managed memory. Under most circumstances, perfectly adequate. But, performance issues are often raised when you have to do complex things on large buffers (a common situation in interactive 3D graphics) – you still have to get down to the metal to get the level of performance you need.

C# does provide for pointer manipulation, but you have to be, to paraphrase an Elmer Fudd quote: vewy, vewy caweful.

Just how careful you have to be was underscored during a code review of some work I’ve been doing. The system has been working quite well, but hangs after visiting a feature in which I’d done some significant work. More maddengly, it hangs in release, but the debug builds appear to work flawlessly.

During the code review, we discovered a utility I had been using (written by another faction in the client’s organization) returned an unprotected pointer to a pretty large buffer. We don’t know if that has been the cause of the hangs, but it is certainly suspect.

Pointer Usage in C# Review

You don’t specifically allocate a chunk of memory in C# and get a pointer to it, under any circumstances. You can create variables, you can create references to variables, but you never get a pointer directly.

Instead, to get to a pointer, you have to use one of two mechanisms:

1. The ‘fix’ mechanism, whereby you assign a pointer to a variable and a block in which you can use that pointer. The construct is very much like a function call:

  fix (float *ptr = someFloatBuf)
  {
     /*
     | You can use the pointer here, but nowhere outside of this scope.
     |
     | You can't modify the pointer, either - you have to use offsets
     | or assign other pointers (that *are* open to modification, since
     | they'll point into your fixed buffer).
     |
     | If you need access to another buffer, simply add another fix
     | statement, like so:
     */
     fix ( float *ptr2 = anotherFloatBuf)
     {
        /*
        | We can access both 'ptr' and 'ptr2' in this block.
        */
     }
  }

2. Through the ‘GCHandle’ mechanism, whereby you create a ‘handle’ on the
   object and get a pointer via that handle. The memory is ‘pinned’ in place -
   the Garbage Collector (the ‘GC’ part of the name) will leave it alone.

  Using System.Runtime.InteropServices
  ...
  GCHandle hFloatBuf = Alloc(floatBuf, GCHandleType.Pinned);
  float *ptr = (float *)hFloatBuf.AddrOfPinnedObject().ToPointer();
  /**
   |  We can use this pointer, anywhere - the only constraint is when
   |  we're done, we need to do the following to release the block back
   |  to the Garbage collector.
   */
  hFloatBuf.Free();

All well and good, but there are things to consider in either approach, and
malignancies that can arise, all worth exploring in the next post.

I’ve extolled the virtues of Qt extensively, and will continue to do so – it’s a great toolkit for cross-platform UI development.

Same for Open Inventor (TGS’ version, particularly), for the 3D graphics world.

But, getting those environments is costly: enough to consider having to mortgage the baby and the house, if you don’t have the backing of a major corporation.

Thus the dilemma I faced when needing to write an architectural feasibility exploration program. What to use?

We had Open Inventor, but no Qt. And I needed it longer than a month, so the trial version was not a consideration. The first attempt was to use our OIV with the straight Win32 API.

Yeah, ok, you can do that, but it’s a lot of lines of code, and it isn’t quick. Not exactly an agile environment. Need to do something better.

The Solution

Web investigations led me to wxWidgets for the UI. wxWidgets might be considered the poor sister to Qt (although devotees would argue that.)

And, for an Open Inventor solution, there is either the horse’s mouth – SGI themselves – or the COIN implementation from the Systems In Motion folks in Finland, who provide an open-source version. The SGI is open-source, too, but it doesn’t come with an SoWin implementation, so COIN looked like the better answer.

And, they’re both free – completely free in the case of wxWidgets – less free, but ok for internal/demo use in the case of COIN.

The Conclusion

They worked great! I had to hook up the SoWin directly into the wxWidgets idle loop, but that’s not onerous. Create an SoWinExaminerViewer, parent it with a win HANDLE (available from the widget), and things were spinning, soon enough.

More to discuss in this line, but they look very promising for low-budget investigations or even products that can’t sustain the full investment of their much more expensive counterparts. This is much more true in the case of wxWidgets, since it’s use is free and completely unrestricted. If you’re going to use COIN in a commercial product, you will have to pay…

More to come…

rickb

Had to put together a small Open Inventor demo program, the other day, using the straight Win32 API.

It’s jarring, to say the least, to go from a fluid development environment like C# back to the cranky C/C++ world – compounded by going from .NET to WinAPI. I had to take a few moments to recollect myself, reset my head to having to deal with synchronizing header files and long builds and the myriad things that can go wrong when they’re out of sync. Like accidentally declaring a pointer outside of a class in a header file. (multiply-defined objects – remember extern?).

But, the reason I had to do this is illuminating, as well: I had to divide the development between the client’s environment, which has the C# adapter for Open Inventor, and my local environment, which does not (cost issues.) Qt might have been a reasonable choice, but 1) Qt isn’t available at the client’s location and, 2) it isn’t available on my home system co-joined with Open Inventor, either.

So, those are always the trade-offs – compatibility with baseline systems at little or no up-front cost (but more work), or shell out the bucks (mucho, in the case of Open Inventor and Qt) to have everything work seamlessly across the board.

Turns out there is, I believe, an alternative set of tools. I’ll be exploring them over the next few weeks.

Stay tuned.

rickb