ansaurus

Question

Answer 1

+2 A:

If you need performance-critical graphics processing, then C++/DirectX or C++/OpenGL are your best bets, hands down. C++/DirectX is arguably the more maintainable of the two.

That said... depending on the actual processing you're doing, you might consider moving portions of your UI to a more maintainable platform. The .NET framework / WPF can do some pretty amazing things, and with good implementation of patterns like MVVM and can be amazingly maintainable. Ditto the networking side; WCF abstracts a lot of common protocols away from the code, making for cleaner, more maintainable networking code. You can even write your translation layer between your unmanaged processing and your managed layer in C++/CLI.

That said, it's all very subjective. I can't tell enough from your bullet points to make a good judgement on whether or not you can offload some or even all of your processing to .NET/C#. It's worth considering, but my gut tells me that it's probably not your best bet.

Randolpho 2010-09-17 02:29:29

Personally, I'm in the process of rewriting an MFC GUI into C#/WPF. Now, I'm not saying the C++ code was well written, but I'm finding it exceptionally easy to write code against C#/WPF that is quick and more responsive than the existing MFC GUI. In part, this is because it is exceptionally easy to do things in parallel in C# in a handful of lines of code which would takes you hundreds, if not thousands, of lines of code in C++. That being said, the MFC controls seem to lag behind WPF in similar tasks like dealing with ComboBoxes that have a large number of items.

Nathan Ernst 2010-09-17 02:46:50

@Nathan: Yeah, I'm a big fan as well. For anything other than, say, 3d games, I usually recommend C#/WPF. In this case I'm on the fence based on his requirements. It could probably be done in C#/WPF -- I'd certainly love to do it in C#/WPF, sounds like a fun project -- and it would be fairly performant, but.... would it be performant *enough*? I just don't know.

Randolpho 2010-09-17 03:09:00

@Randolpho, agreed, without further details, one can't say. My experience says that the argument that we can't/shouldn't write in C# because the C++ is "fast" is usually bogus, as the comparative C++ code is usually crap and inefficient. Caveat, this is a generalization, and I write C++ primarily. But, I see a lot of *cough* shit *cough* code that is "fast". Most C++ code I see I can write faster code in python. Management perceptions can be a bitch to overcome, though.

Nathan Ernst 2010-09-17 03:17:58

Should also note it took a metaphorical gun to our head before I convinced management on python. I had 3 weeks to write from scratch, with no internal libs, an app to migrate financial positions in an arbitrary format to a central clearing counterparty. They were convinced when I could migrate 1 million positions in less than 10 minutes and the code was flexible enough to change to rapidly incoming requirements changes.

Nathan Ernst 2010-09-17 03:21:24

@Nathan Ernst: you won't get any arguments from me on performance. For 99% of all options, managed, JITted code in the form of C#, Java, or Python (with Unladen Swallow, PyPy, or Psycho) is just as fast if not frequently faster than (for long-running processes) unmanaged code. There remain caveats, of course, particularly in the graphics department, but... yeah.

Randolpho 2010-09-17 04:47:28

Additionally, @YeenFei, based on your edit, I think C# may do the trick, although the actual processing you're doing will be complex and difficult in any language. If your processing library is mature and stable, it might not be wise to mess with it.

Randolpho 2010-09-17 04:48:40

@Randolpho, the processing library are matured CoTS and some even had .net support in newer version. However, our "BL" (@result logic) layer is quite legacy (and lengthy, of course!) which worried me if it is required to be ported onto .net

YeenFei 2010-09-18 01:06:48

Answer 2

+2 A:

As a fan of Qt I would be remiss not to mention it.

Although cross-platform is not one of your criteria, it is a nice bonus.
Qt also has good video hardware support through OpenGL (I'm not sure that it will help with capture hardware though).
It is open-source so you can get your hands as dirty as you like.
It is highly customizable.
It is actively developed and has a large community.
MFC programmers should not have much trouble coming up to speed.

You should also read through some of these questions and answers:

http://stackoverflow.com/questions/115045/good-c-gui-library-for-windows http://stackoverflow.com/questions/610/gui-programming-apis

Arnold Spence 2010-09-17 02:35:12

I would agree with Arnold. Qt is a good choice these days. I used it on my last contract job for a medical device and it's fine. I particularly appreciated the signal slot mechanism.

ExpatEgghead 2010-09-17 04:29:47

Answer 3

+1 A:

What I had did before when developing a C++ scientific application is that, it will develop it completely under console based application. The console based application will able accept various type of command from user keyboard, and perform action accordingly. For example :

image_processor > load input.png
image_processor > save out.png

The good thing on this is, I can 100% in concentrating my algorithm design, without worry much on how to fit into the GUI framework. Either they are MFC or QT.

At the end of day, instead of taking input from keyboard input stream, I will just simply hook my console based application's STDIN, to the GUI application communication channel. My GUI application will then string based command, to talk and receive feedback from the console application.

Guess what I use to develop the GUI? Java Swing :)

I guess I am taking Unix people approach. See what Joel says :

Suppose you take a Unix programmer and a Windows programmer and give them each the task of creating the same end-user application. The Unix programmer will create a command-line or text-driven core and occasionally, as an afterthought, build a GUI which drives that core. This way the main operations of the application will be available to other programmers who can invoke the program on the command line and read the results as text. The Windows programmer will tend to start with a GUI, and occasionally, as an afterthought, add a scripting language which can automate the operation of the GUI interface.

I realize by taking Windows approach, you will end up with a more user friendly application. However, if your main concern is to get the sophisticated algorithm written well and GUI is the secondary, I would suggest that you go for Unix approach.

Yan Cheng CHEOK 2010-09-18 06:25:46

ansaurus

tags:

views:

answers:

Application GUI development platform

related questions