View Single Post
Old 07-21-10, 04:19 PM   #29
kRogue
Registered User
 
Join Date: Jan 2005
Posts: 19
Default Re: is the nvidia driver falling behind?

Quote:
I was under the impression that the exact opposite is true.
After dealing with the internals of Qt I have enough personal experience to say GTK/GDK is better. Here are a few reasons:

1) GTK/GDK is much better modularized. This is a known issue at Trolltech too, so much known that they want to take steps to address it.

2) Qt does many things, and it does very few of those things well:
a) Qt container classes are inferior to STL. Things begin to look really bad if you are also a boost user. Qt's container classes insistence on "copy on write" is a horrible idea. C++ has const reference for a reason. Qt coding style is to pass containers by _value_, underneath no copy occurs, unless the function called writes to the container, then *boom*. Additionally, because of this, lots of care needs to be taken to that one does not ask for data in some raw form that forces a copy to be made (use correct call to get pointer to data , etc).

b) Drawing is pants, but I've already biled this enough.

c) JaveScript: Qt's Javasript engine is junk compared to many others. Unfortunately, due to Qt's "friends everywhere" in it's source code (all hidden by the pimple paradigm from the consumers of Qt) one cannot just replace the Javescript engine with another one that runs faster.


d) Qt's object model and MOC are left overs from like 10 years ago from when C++ compilers did not correctly implement RTTI, unfortunately, moc is in Qt to stay.

e) Qt's signal and slots is inferior to boost's signal and slots which are now thread safe too. One of the worst sins of Qt is how one connects signals to slots: by name as a string. The name resolve is done at RUN time, so if you typo a name, the compiler cannot pick it up, you need to spot the debug message from Qt that it did not connect. I suppose this might be useful for when you don't want to include the header file of the class you are wiring a signal to, but no. That is a bad idea. There are much better ways to do plugins.

f) Qt's build system is kind of a sick twisted thing: use qmake to make a makefile... there are all sorts of inflexibilities with the thing. There are better build systems already: bjam, cmake, and some people still like to make their own makefiles.

g) Qt IO interface is painful to use, worse it is a big step backwards from standard C++ iostreams, coupled with boost::iostreams it looks even worse.

h) Qt has a fair number of layer libraries over standard libraries that provide almost 0 additional functionality. Worse, a fair number of them are out of date to what they are wrapping (GL --> QtOpenGL, CL--> QtOpenCL).. worse, for OpenCL, there is CL/cl.hpp, a C++ interface to OpenCL provided by the people who make the OpenCL standard, Khronos. Make a guess which is better to use.

i) Qt's QGraphics Framework is a lesson in poor design and failure. There are a high number of flags that interact with each other, each producing different and surprising results. QWidget's have lots of flags too. The Qt documentation on these flags is ass poor. Only real way to see what they do: open up Qt source code.

j) even on the simple 3d math side, Qt has screwed up; they could have optimized it so that it was high performance (i.e. use SSE and get the alignment correct). But that was not the case at all. It looks like a high school science student project, at best. The matrix classes induce branching, as each matrix has an additional integer tag. Qt uses that integer to say if the matrix is a rotation, translation etc... except they have no code to compute that flag really, rather once a translation matrix is mutiplied by a rotation even if you apply the inverse rotation, there is nothing to realize is should be "close" to a translation and then remark as such. The consequences of this are all sorts of nasty surprises later.

k) Building Qt on MS-Windows can be painful, very, very painful. Try building Qt with MinGW. Enjoy.

There is more, but I will stop there.

Quote:
I had built a qt-opengl package back then (a qt package with default graphics system opengl), however it was completely broken-unusable (menus and icons had random artifacts or disappeared randomly etc.).

I haven't tried with qt 4.6.x the same. Would it be worth it, or a waste of time?
Qt 4.6's GL2 backend is heck a better, but there is a catch to use it: you need GL2.x capable hardware, that means working GLSL. Framebuffer object support is a good idea but not required. MSAA support is a really good idea too. If you are using NVIDIA hardware and drivers you are safe. However, Qt's GL using patterns are bad, don't expect amazing performance. However, you will need to rebuild all of Qt to use it. Also, if you are using KDE4, make sure your custom built Qt does not bork you distro's Qt.... install your Qt in it's own place (like /usr/local/Trolltech/Qt.something) modify our PATH and let LD_LIBRARY_PATH be your friend.
kRogue is offline   Reply With Quote