Coming from C++ & MFC background, is there any better (maintainability/customization) platform in developing application GUI ?
We are developing industrial applications (machine vision), where :
-Performance-critical (mostly image processing in CPU atm, but GPU is up next)
-Low level hardware interfacing (inhouse PCI device, frame grabber, motion card)
-Real-time data visualization (images / statistical graph)
-Future roadmap includes networkability for distributed processing and remote access.
Cross-platform will not be important for us since the system runs in controlled-environment (customer only cares whether the system runs and they got their output).
There are also concerns on migration cost (3rd party dependencies, training cost for developers and service personnel)
Edit
Clarification on the "image processing" mentioned above:
I'm referring to "picture" (2D information in matrix format) rather than graphic (commonly 3D vectorized). Currently we uses 3rd party imaging library (for spatial domain processing like segmentation, OCR/OCV, morphology, pattern match) and incorporate our result logic.
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.
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:
Good C++ GUI library for Windows
https://stackoverflow.com/questions/610/gui-programming-apis
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.
Related
I need to develop an application that can be run on both Windows and Mac OS X, is a application "monitor" that needs to display data in real time, connection over ethernet. I'm interested in the performance and graphics. I know very well the c++. can you help me in choosing a development tool?thank you
JUCE is not just about for Music industry. Its for all. I have used it in Music softwares, Image processing and only GUI applications too.
Its a well built library which supports all platform.
you need not to create different project files for the application. JUCE creates it for you.
And its pure C++.
I would say your two choices are Juce or Qt. Juce is geared toward audio and graphics, letting you get your hands on creating fast and powerful DSP algorithms. Although Juce's largest following is with developers making music software, it's fully capable of making general purpose applications with the same ease as Qt. Qt does have advantages resulting from it's greater adoption; you will find plenty of tutorials, books and courses on Qt but hardly much on Juce at the moment.
Hopefully that will change soon as Juce was bought out by ROLI and will likely have more resources soon.
Is it possible to write GUI application without using GUI toolkit ? As the GUI toolkit like GTK+ itself is written in c language, when there were no such toolkits at starting so how could programmers developed GUI apps only using c or c++ without using such toolkits? How can one write Gui application in c or c++ without using any GUI toolkit?
You can program Windows GUI applications using the Win32 API directly, without using any separate toolkit like GTK+. One reference on how to do that is here: http://www.winprog.org/tutorial/start.html
It's not so common these days, and not for the faint of heart.
Doing GUI stuff at the API level in Windows is not difficult, but involves a lot of work.
As a starting point you can check out my old Windows API programming tutorial “Lessons in Windows API Programming (C++)”.
Going that route you would do well to obtain a copy of the 5th edition or earlier (not 6th or later) of Charles Petzold’s “Programming Windows”, which is considered the Bible on the subject.
You start with a frame buffer for the graphics, upon that you write a set of primitive functions to do basic geometry (lines, circles, polygons, bit copies). Then you create an event queue, and a way to populate it with input events (keyboard, mouse, etc.).
You'll also need to create font and text routines.
Those are the basics upon which any GUI are built, as basic guis are little more than boxes that take click events, and eventually keyboard events.
It's a lot of work.
If you want to look at GUI programming at a lower level, consider looking up are it was originally done in the primitve OSes (such as early Windows, early Mac OS, early X Windows).
Mac OS made much of the work explicit. It offered a Window Manager, and other high level controls, but with a bit of study you can see how these were built on top of Quickdraw (MacOS graphics primitive library).
None of this addresses the modern issue of GPU acceleration and the like, that's a completely different layer of complexity to the problem.
Some googling has led me to believe that C++ is the best language for real-time 2D graphics programming, but since the Android is Java-based, is that still the best option? Or us the fact that I have to use NDK going to slow it down or something? My program also has a lot of scientific computing and I know C++ is best/fastest for that...
I've never done anything with the Android before so I'm really helpless right now. If I'm just going about it the wrong way, please give me other suggestions... Some other vocab I came across is OpenGL (which I have experience with, but that's more for 3D, right?) and Canvas (don't quite get this)? If I could get access to GPU-like capabilities that would be great.
Android applications are written Java, yes - however the Android NDK allows you to write performance-critical sections of your program in C or C++. From the Android NDK website,
The Android NDK is a companion tool to
the Android SDK that lets you build
performance-critical portions of your
apps in native code. It provides
headers and libraries that allow you
to build activities, handle user
input, use hardware sensors, access
application resources, and more, when
programming in C or C++.
That said, using the NDK appropriately will most likely not slow your program down.
OpenGL works for 3D and 2D graphics - if you're only interested in 2D you will want to look at using an Orthographic Projection - see glOrtho for more information. The Android Canvas, on the other hand, is the Java method for drawing raster graphics to the screen. It will let you render 2D graphics, but at a slower rate (and with frequent interruptions from the Android Garbage Collector).
Keep in mind that if you want to use C++, as of writing, there is no STL implementation available. There are, however unofficial ports that provide most of the functionality. STLPort is one that I have tried with some success. The biggest reason to move code to C/C++ is because of interruptions from the Android Java Garbage Collector - if you're not overly careful with your code, it will interrupt your program frequently to clean up objects you've left lying around. In practice this can limit game or simulation framerates drastically.
All that said, I would strongly recommend you look into one of the few open source android game engines that are cropping up. The best one I've tried is libGDX. It takes care of all the messy NDK details and lets you code your game / simulation purely in Java. It automatically runs the performance-heavy parts of the game engine in native code to get the fastest possible performance with the ease of coding in Java. Best of all, you can write your application code once and have it automatically run on Windows, Linux, OSX and Android - which makes testing your applications much, much easier than using the Android Emulator.
If you really want to look into the NDK yourself, or need to have really fine control on what OpenGL is doing, I would recommend you download the Android SDK and NDK, get eclipse set up, and then start with the NDK samples. There is an OpenGL demo there that shows you how to get everything set up. Another good starting point would be the SpinningCube google project.
EDIT: I'm not really sure if what you mean by 'GPU-like capabilities', but With libGDX, you can compile vertex and fragment shaders under OpenGL ES 2.0 - you could use this to run embarrassingly parallel code using the device's GPU.
You're making the assumption that the Android system will be too slow to do what you want, without any data to back that up. Write some tests in Java, and test out the performance first. You don't want to make assumptions about performance without any basis.
Premature optimization is the root of
all evil. - Knuth
How to do it: C-programmers guide to Java and JNI in Android
Good question, I put myself like 1½ years ago, found it very annoying. I feel a lot for you!
And because of this I like to give a hands on answer.
But look it is easy if you follow this guideline step by step (you will have much less struggle). I did it.
Learning this, you can in no time learn easily write Java Netbeans GUI with JNI apps (for any other OS) also, you are in the Java GUI JNI development world?
The basis is “knowing C/C++ very well, not knowing Java or Android programming at all, coming from for instance the Win32 SDK culture and making the first Android app”.
Android GUI is Java – you have to yield
Thing is that the GUI of Android is Java. Java like your app and the app is more or less in practice a piece of the GUI/OS environment completely integrated calling Java GUI SDK code all the time. The debugger even goes into the Java GUI SDK source code (feels like going off road, real odd for a Win32 SDK programmer).
In short, no way writing any Android apps, but in Java.
But it is pretty easy in anyway, you got the JNI
There are three very good shortcuts:
The Android sample library (is very rich), especially the Hello JNI sample is really important
The fact Java is in syntax very much alike C/C++ (but very different in its soul, read below, you need to understand)
You got the JNI C-code opportunity in doing the heavy work (and you major share of the code)
You have to write a small Java Android GUI user interface for your app (by thieving form samples) and the major part JNI, where you write your C/C++-code doing all the work.
Start with the Hello JNI sample program
Install Java and Android Studio and that it is all you need in tools (available in Win10, OSX or Ubuntu, they are the same).
Start Android Studio and its generic picture is a menu, select the lowest, Import an Android code sample.
The main sample program for a traditional C/C++ programmer is Hello JNI. Select it and say next to everything.
The Android Studio editor will open with the sample code (chews somewhat first see status line low).
Up to the right you (might need to push the Android tab to) see the content of your project Hello JNI, app. It consists of:
Manifests (app declaration, today of minor importance because most is now in Gradle script declarations (below))
Java tab for the Java files
Cpp-tab for your C-code files
Resources (texts, menus and icons)
Gradle compiling scripts
C-make-files
The Android studio might ask you for installation plugin upgrades, say yes to everything until it is done (see status line below).
Then run the Hello JNI sample code, to make certain your installation is OK
Pushing the green arrow in a cogwheel (mid top).
You get a dialogue box. Here you can try the sample on:
A physical Android device (via a cable from your PC, might need a Samsung win driver from their support)
A HAXM Android unit emulator (is reel good)
But you need to switch off the Hyper-V feature (used for XP emulation) in Win10 to make it run. Android studio might do it automatically for you asking, else control panel/Programs and functions/Windows functions.
Select Create new Virtual device. You might need to do some installation plugin upgrades more, say yes to everything.
When the Hello JNI app is working in the device, you have an OK installation.
C-code, check hello-jni.c
Look in the cpp-folder Up right) and you will find a C-file with a function.
Here and in any other C-file you can fill it with regular C-code.
Everything but the ANSI C locale features are supported (must get locale data from Java and transport them to the C-environment).
You need to edit the CMakeLists.txt file to add any additional C/C++-files (it is the makefile, look up to the right under the Gradle scripts).
Memory heaps, Java with JNI and C are different
You must be aware that everting in the data jstrings delivered by the JNI interface is located in the Java memory heap. This is also the case after the data has been in delivered C-format by JNI.
You will have fuzz if you don’t copy string data (and arrays) from the Java heap to the C-heap. Make a basic function like this to copy the data and release the JNI data:
char *GetStringfromJniString(JNIEnv *env, jstring jniString)
{
const char *TempString = (*env)->GetStringUTFChars(env, jniString, 0);
char *String = calloc(strlen(TempString) + 1, sizeof(char));
strcpy(String, TempString);
(*env)->ReleaseStringUTFChars(env, jniString, TempString);
return String;
}
When you send data to Java jstrings you need to contain it to the JNI transport by using the
return (*env)->NewStringUTF(env, pCstring);
Long funny names of the JNI-functions
The function name is Java_com_example_hellojni_HelloJni stringFromJNI(…).
There “Java” is always there
com_example_hellojni means it communicate with your app in the Java com.example.hellojni Java package (read about it in the tutorial)
The HelloJni is the name of the Java file the JNI function is declared
And stringFromJNI(…) is the actual function name (functions in Java are called Methods).
If naming is OK the declaration of the C JNI-functions in the Java file is black text, if not red text. (Give it a chance, it stores and checks the code continuously in the Java environment, might take a few seconds to verify it is right (becoming black).
You must declare the C JNI-functions in java
In the Java file here HelloJni.java the JNI-functions must declared as Java Methods (functions in Java).
public native String stringFromJNI(…);
Where return values and function/method switches are the same as in C.
After that you can use the JNI-functions as Java methods as they are declared in the Java declaration. Note that char * is String in java.
Constants must be declared on both sides
#define CONSTANT_A = 24
Is in Java
static final int CONSTANT_A = 24;
And you can use them in Java and in C as usually.
if(!variable) does not work in Java
You need to do
if(variable==0)
Test other samples
The sample library is full of fully nice functioning Java samples. Try them one by one until you find a user interface of your like. It is actually nice to test samples.
There are a lot of sample in Github but a lot of them need fixes of Gradle scripts or comes from Eclipse (the past Android dev environment) and is harder to try (often need fixes). Other Github sample are just fragments and a lot of work making them working. Of course nothing for a Java Android star but we are not there yet. But Github a very good even larger source of samples.
Copy the Java stuff into your Hello-JNI
Found anything nice, copy it!
Theft always pays as JS Bach used to do!
It is quite easy to just copy stuff from one sample to another. When copying in the Android studio, Android studio adds automatically the includes (asking first) and just accept. Sometimes it does it asking you to enter Alt-Enter, do it.
Editing several projects at the same time
The File/Open recent - Own windows-command, make you having two projects up at the same time, easier to copy stuff in between.
Making your own application
After some testing you create your own app.
Go to the generic Android studio picture (file/close project), select Start a new Android Studio project. Put your Package tree data (think that over, read about it in the tutorial) and create it. Then copy the stuff you tested to your own app.
Learn Java, the Android developer tutorial is real good
Now you have made your environment working and spotted some good user interfaces, learn Java!
The Android Studio tutorial is real good. Try it, and soon after a few lessons you will be able to play with Java code and very soon you are a Java programmer.
Getting stuck, google and you find most answers in Stackoverflow, just search.
You are never the first with a problem and Stackoverflow is real good. Read all the answers and think, you find what fits you best.
The Java environment and Android OS is very different from Windows
You need a feeling for the culture and environment. Like a Swede coming to Norway, the same food taste slightly different, even if it looks the same.
The major difference is that in Java nothing crash as good as in pure C in a C environment. Finding bugs can be hell because of non-consistent crashing. The program continue to run and crash later, but you find the bugs.
There are Java log files for debugging, but it takes quite an effort to penetrate it. Like learning the assembly code in a Windows debugger.
A good idea is to really debug the C-code in a pure C-environment first and handle the Java stuff in Android Studio.
I can amend C-code in Android Studio but writing a large chunk of C-code is really looking for troubles debugging it. Like asking a Norwegian make a Swedish dinner, impossible to get it right, looks the same but taste different. Nothing is wrong but different culture.
The soft crashing style of Java includes even security soft crash features like the try/catchy/finally stuff. (You have to google and read about it yourself. It is unbelievable for a hard core C-programmer, but it is real.)
There are no h-files and #if-compiler switches in Java
Instead of h-files and common declarations of functions/variables as in C in java you have to refer to them with a filename followed by a dot and the method name, using them from another file.
If declared private variables and methods can only be accessed from the same file, with public can be used with file reference. Static is something very different in Java.
There are no compiler #if-switches so you need to use regular variables/constants (for constants put final before in the declaration).
There are no pointers in Java, but there are strings
There are no pointers in Java but a String (and array) variable is in fact a char pointer
But you can’t handle pointers as in C with * and &, but in JNI you certainly can. The memory management is completely different, nothing is fixed in Java.
You don’t need to free data, Java wipes it all for you
Java cleans unused data automatically.
You don’t free data just delete (=0;) the string-“pointers” or just leave the method (Java function) and it cleans it.
So if you have a string pointer and just replace it with something else the old stuff is automatically wiped.
The Java environment lives its own life, but the Android studio debugger includes a monitor of the data used.
Size limitations of Java apps and JNI code
Good to know is that there are some restrictions in how large a Java app can be (but as usual nothing is written in stone in Java) but the JNI heap can be as large as the HW can take.
But you are not alone in a phone, an incoming call might come and you don’t want to mess that up? If you clean well it is a larger chance your app is intact returning to it and not killed.
Android apps don’t die by exit
If you exit an app, the app is still running even though the GUI is gone (like in Macintosh). Thing is that you have to be aware of that, read about it if you make serious apps.
Android kills apps
But on the other hand you can never trust that an app is not wiped by the OS and you have to rebuild. If the OS need memory it just starts to kill apps. But the JNI part usually survive and you can store data there for a recovery.
There is only one JNI instance (WinSDK term) but there might be many Java instances
And them all connect to the same JNI at the same time. Only one app instance can be active (shown) but the others might make background tasks. In JNI you need to keep track of them.
Normally there is only one Android instance of every app. But if you start the app by a work files from for instance like an email client, you in fact have another instance of the app (with its own memory and everything (but the JNI that is in only one common instance)).
Starting an appended file there will be two or more Android instances. Each related to each email instance, by the intents procedures (learn about intents in Android tutorial).
A smart thing is keeping track of the instances by number them when the app is created if savedInstanceState == null.
Copy data to the emulated unit
You might need to upload some data to test your app. In a regular phone you just attach the USB-cable and enter the Phone storage from Windows explorer. With the emulated units you must use the adb-terminal script functionality (can be used in bat-files in Windows and a copy bat file looks like this:
PATH=%PATH%;C:\Users\You\AppData\Local\Android\sdk\platform-tools
adb push C:\Users\You\Documents\v.txt /storage/emulated/0/Android/data/com.yours.app/files/v.txt
Very limited privileges to read and write files
Thing is however that you are only allowed to open your own files stored by your app in the emulated SD card. Else nothing comes reading them.
Use standard ANSI C file functions rather than Java
Best in a C-heavy app is to use standard C- file functions, as a C-programmer you are used to them and their behavior.
The C-file functions works fine and is easier to get binary code or transparent text files with ctrl-characters etc (Is not allowed in Java Strings but in java bit arrays). Take some effort learning Java file handling if you try that.
JNI performance is no issue
The C-code is much faster than the Java code so a lot of developers not from the C-culture must make JNI-functions and pure C-code to perform in heavy apps, needing performance. In short JNI performance is no issue.
However I have the impression that the Android GUI is faster than the WinSDK GUI in many cases. Working with ListViews and sometimes very long lists, Android is far better optimised. It looks like WinSDK is loading every line of the list, but Android only the lines visual, and in long lists it makes a huge difference.
I am impressed by performance in Android even with tiny ARM processors. Apps do perform very well. Intel Android units are real good in performance. I wouldn't hesitate trying to make a heavy duty app in Android, as long as I use JNI. Does not come short compared to Windows.
But notice, that running HAXM in an Intel PC the Intel emulated units runs much faster than the ARM than in real HW-units, because it runs intel code straight and not over an emulator layer as with ARM emulated units.
I am amazed that the Android x86 is not marketed heavier as a competitor to Windows on netbooks, for the common man, doing some documents, some calculations, email and Google? I believe the Crome OS is too alien for most people and most people have Android phones, feeling home. As a SW vendor I would like to see Android netbooks marketed much more and I would put more effort in SW development. Same thing with the Android TV without menus is closing the market for just the old Smart-TV approach. Something I can't understand having a boxed Win10 on the back of my TV since years, using a lot of programs there. The lack of Android graphics driver for the Raspberry-pie is also hard to understand, one with a regular Android would be smashing attached to the TV. In Sweden where I live, people under 40 don't watch aired TV, they stream, public service play, YouTube and Cable TV operators packages over internet. Having regular Android in the TV would generate usage of a lot of other apps. I see a market opportunity for SW vendors is closed. This when MS is making suicide with leased SW (normal people don't pay) mixing the culture of large accounts with the common man, a huge marketing window is opened. And the Android app performance is real good and nothing to worry about. It is not performance but marketing policies that limits the app market.
Quick you become a Java and Android master
You will be surprised how easy Java is for a C-programmer, doing it the right way (like following this guideline).
It might be slightly harder for a C++-programmer because the Classes in java and C++ culture looks to vary, might be easier to learn Java classes from scratch? But if you see C++-code in Win32 and OSX environment they look usually from different planets, so they might use to it.
The major disadvantage is that you wouldn’t get a diploma for your CV as doing a programmers course?
I want to create a C++ UI framework (something like QT or like ubuntu unity Desktop)
How is programmed , is it using OpenGL or lets take plasma ui of QT (how is this programmed )?
Direct answers , reference links anything will be helpful.
Some interesting opengl based UI I founf on the web
LiquidEngine
http://www.youtube.com/watch?v=k0saaAIjIEY
Libnui
en.wikipedia.org/wiki/Libnui
Some UI frameworks render everything themselves, and work based on some kind of clipping-window-within-the-host-systems-screen. Non-display aspects (such as input event handling) have to be translated to/from the host systems underlying APIs.
Some UI frameworks translate as much as possible to some underlying framework.
wxWidgets can do both. You can choose a native version (e.g. wxMSW if you're on Windows) and most wxWidgets controls will be implemented using native Windows controls. Equally, you can choose the wxUniversal version, where all controls are implemented by the wxWidgets library itself.
The trouble is that typical GUI frameworks are huge. If you want a more manageable example to imitate, you might look at FLTK. I haven't got around to studying it myself, but it has a reputation for being consise.
There are also some GUI toolkits that are specifically aimed at games programming, such as Crazy Eddies GUI. My guess - these are probably as idependent of the underlying API as possible, so that particular applications can implement the mapping to whichever underlying API they happen to target (OpenGL, DirectX, SDL, whatever) and can be the boss of the GUI rather than visa versa.
http://www.wxwidgets.org/
http://www.fltk.org/
http://www.cegui.org.uk/wiki/index.php/Main_Page
"no really, don't write your own wm or toolkit"
The #Xorg-devel guys on irc.freenode.org
doing one anyway means that you have to test against a wide range of more or less buggy WMs and X implementations, and that you have to frequently update to be compatible with the latest Xorg server and X protocol features (like Xinput 2.1)
understandably, the Xorg people are tired to support old, unmaintained toolkits and applications. They already have enough bugs.
The GUI frameworks are very dependant on a windows system, which dictates what is allowed and how windows are created and rendered. For example, pass a specific option to create a borderless or full-screen window.
Since you mentioned opengl and ubuntu, I guess you want to start on a linux platform. You should study xlib, for which you can find reference here.
Since the qt library is open source, you can download it and peek into it's sources.
A UI library isn't developed from scratch. It relies on the OS' windowing system, which relies on the driver from your graphics adapter, which relies on the OS kernel, which relies on... and so on.
To develop any software "from scratch", you can start by writing your own BIOS. Once you're done with that, move on to writing an OS, and then you should be just about ready to write the software you wanted. Good luck.
And this is assuming you're willing to cheat, of course, and use a compiler you didn't write from scratch.
Before you do that, it's worth that you spend one week on thinking:
1, Do you really know how to do it? I doubt that.
2, Do you really need to do it? I doubt that too.
I'm considering writing a new Windows GUI app, where one of the requirements is that the app must be very responsive, quick to load, and have a light memory footprint.
I've used WTL for previous apps I've built with this type of requirement, but as I use .NET all the time in my day job WTL is getting more and more painful to go back to. I'm not interested in using .NET for this app, as I still find the performance of larger .NET UIs lacking, but I am interested in using a better C++ framework for the UI - like Qt.
What I want to be sure of before starting is that I'm not going to regret this on the performance front.
So: Is Qt fast?
I'll try and qualify the question by examples of what I'd like to come close to matching: My current WTL app is Programmer's Notepad. The current version I'm working on weighs in at about 4mb of code for a 32-bit, release compiled version with a single language translation. On a modern fast PC it takes 1-3 seconds to load, which is important as people fire it up often to avoid IDEs etc. The memory footprint is usually 12-20 mb on 64-bit Win7 once you've been editing for a while. You can run the app non-stop, leave it minimized, whatever and it always jumps to attention instantly when you switch to it.
For the sake of argument let's say I want to port my WTL app to Qt for potential future cross-platform support and/or the much easier UI framework. I want to come close to if not match this level of performance with Qt.
Just chiming in with my experience in case you still haven't solved it or anyone else is looking for more experience. I've recently developed a pretty heavy (regular QGraphicsView, OpenGL QGraphicsView, QtSQL database access, ...) application with Qt 4.7 AND I'm also a stickler for performance. That includes startup performance of course, I like my applications to show up nearly instantly, so I spend quite a bit of time on that.
Speed: Fantastic, I have no complaints. My heavy app that needs to instantiate at least 100 widgets on startup alone (granted, a lot of those are QLabels) starts up in a split second (I don't notice any delay between doubleclicking and the window appearing).
Memory: This is the bad part, Qt with many subsystems in my experience does use a noticeable amount of memory. Then again this does count for the many subsystems usage, QtXML, QtOpenGL, QtSQL, QtSVG, you name it, I use it. My current application at startup manages to use about 50 MB but it starts up lightning fast and responds swiftly as well
Ease of programming / API: Qt is an absolute joy to use, from its containers to its widget classes to its modules. All the while making memory management easy (QObject) system and mantaining super performance. I've always written pure win32 before this and I wil never go back. For example, with the QtConcurrent classes I was able to change a method invocation from myMethod(arguments) to QtConcurrent::run(this, MyClass::myMethod, arguments)and with one single line a non-GUI heavy processing method was threaded. With a QFuture and QFutureWatcher I could monitor when the thread had ended (either with signals or just method checking). What ease of use! Very elegant design all around.
So in retrospect: very good performance (including app startup), quite high memory usage if many submodules are used, fantastic API and possibilities, cross-platform
Going native API is the most performant choice by definition - anything other than that is a wrapper around native API.
What exactly do you expect to be the performance bottleneck? Any strict numbers? Honestly, vague ,,very responsive, quick to load, and have a light memory footprint'' sounds like a requirement gathering bug to me. Performance is often overspecified.
To the point:
Qt's signal-slot mechanism is really fast. It's statically typed and translates with MOC to quite simple slot method calls.
Qt offers nice multithreading support, so that you can have responsive GUI in one thread and whatever else in other threads without much hassle. That might work.
Programmer's Notepad is an text editor which uses Scintilla as the text editing core component and WTL as UI library.
JuffEd is a text editor which uses QScintilla as the text editing core component and Qt as UI library.
I have installed the latest versions of Programmer's Notepad and JuffEd and studied the memory footprint of both editors by using Process Explorer.
Empty file:
- juffed.exe Private Bytes: 4,532K Virtual Size: 56,288K
- pn.exe Private Bytes: 6,316K Virtual Size: 57,268K
"wtl\Include\atlctrls.h" (264K, ~10.000 lines, scrolled from beginning to end a few times):
- juffed.exe Private Bytes: 7,964K Virtual Size: 62,640K
- pn.exe Private Bytes: 7,480K Virtual Size: 63,180K
after a select all (Ctrl-A), cut (Ctrl-X) and paste (Ctrl-V)
- juffed.exe Private Bytes: 8,488K Virtual Size: 66,700K
- pn.exe Private Bytes: 8,580K Virtual Size: 63,712K
Note that while scrolling (Pg Down / Pg Up pressed) JuffEd seemed to eat more CPU than Programmer's Notepad.
Combined exe and dll sizes:
- juffed.exe QtXml4.dll QtGui4.dll QtCore4.dll qscintilla2.dll mingwm10.dll libjuff.dll 14Mb
- pn.exe SciLexer.dll msvcr80.dll msvcp80.dll msvcm80.dll libexpat.dll ctagsnavigator.dll pnse.dll 4.77 Mb
The above comparison is not fair because JuffEd was not compiled with Visual Studio 2005, which should generate smaller binaries.
We have been using Qt for multiple years now, developing a good size UI application with various elements in the UI, including a 3D window. Whenever we hit a major slowdown in app performance it is usually our fault (we do a lot of database access) and not the UIs.
They have done a lot of work over the last years to speed up drawing (this is where most of the time is spent). In general unless you really do implement a kind of editor usually there is not a lot of time spent executing code inside the UI. It mostly waits on input from the user.
Qt is a very nice framework, but there is a performance penalty. This has mostly to do with painting. Qt uses its own renderer for painting everything - text, rectangles, you name it... To the underlying window system every Qt application looks like a single window with a big bitmap inside. No nested windows, no nothing. This is good for flicker-free rendering and maximum control over the painting, but this comes at the price of completely forgoing any possibility for hardware acceleration. Hardware acceleration is still noticeable nowadays, e.g. when filling large rectangles in a single color, as is often the case in windowing systems.
That said, Qt is "fast enough" in almost all cases.
I mostly notice slowness when running on a Macbook whose CPU fan is very sensitive and will come to life after only a few seconds of moderate CPU activity. Using the mouse to scroll around in a Qt application loads the CPU a lot more than scrolling around in a native application. The same goes for resizing windows.
As I said, Qt is fast enough but if increased battery draining matters to you, or if you care about very smooth window resizing, then you don't have much choice besides going native.
Since you seem to consider a 3 second application startup "fast", it doesn't sound like you would care at all about Qt's performance, though. I would consider 3 second startup dog-slow, but opinions on that vary naturally.
The overall program performance will of course be up to you, but I don't think that you have to worry about the UI. Thanks to the graphics scene and OpenGL support you can do fast 2D/3D graphics too.
Last but not least, an example from my own experience:
Using Qt on Linux/Embedded XP machine with 128 MB of Ram. Windows uses MFC, Linux uses Qt. Custom user GUI with lots of painting, and a regular admin GUI with controls/widgets. From a user's point of view, Qt is as fast as MFC. Note: it was a full screen program that could not be minimized.
Edited after you have added more info:
you can expect a larger executable size (especially with Qt MinGW) and more memory usage. In your case, try playing with one of the IDEs (e.g. Qt Creator) or text editors written in Qt and see what you think.
I personally would choose Qt as I've never seen any performance hit for using it. That said, you can get a little closer to native with wxWidgets and still have a cross-platform app. You'll never be quite as fast as straight Win32 or MFC (and family) but you gain a multi-platform audience. So the question for you is, is this worth a small trade-off?
My experience is mostly with MFC, and more recently with C#. MFC is pretty close to the bare metal so unless you define a ton of data structure, it should be pretty quick.
For graphics painting, I always find it useful to render to a memory bitmap, and then blt that to the screen. It looks faster, and it may even be faster, because it's not worrying about clipping.
There usually is some kind of performance problem that creeps in, in spite of my trying to avoid it. I use a very simple way to find these problems: just wait until it's being subjectively slow, pause it, and examine the call stack. I do this a number of times - 10 is usually more than enough. It's a poor man's profiler but works well, no fuss, no bother. The problem is always something no one could have guessed, and usually easy to fix. This is why it works.
If there are dialogs of any complexity, I use my own technique, Dynamic Dialogs, because I'm spoiled. They are not for the faint-of-heart, but are very flexible and perform nicely.
I once made an app to determine the "primeness" of a number (whether it was prime or composite).
I first attempted a Qt GUI, and it took 5 hours to return the answer for 1,299,827 on a computer with 8GB of RAM and an AMD 1090T # 4GHz running no other foreground processes under Linux.
My second attempt used a QProcess of a console application that used the exact same code. On a laptop with 1.3GB of RAM and a 1.4GHz CPU, the response came with no perceivable delay.
I will not deny, though, that it is far easier than GTK+ or Win32, and it handles things quite nicely, but separate intensive processing ENTIRELY from the GUI if you use it.