View Single Post
Old 07-24-10, 02:07 AM   #35
kRogue
Registered User
 
Join Date: Jan 2005
Posts: 19
Default Re: is the nvidia driver falling behind?

I do stand corrected there are a fair number of API points in Qt that pass by const reference, actually quite a few .. even the QPainter API is mostly pass be reference, my definite bad... though, must to make it clear, underneath at the implementation it is ugly, horribly ugly.

As for the JavaScript bits: I am not proposing a public API, but internally to Qt so that changing Javascript engines is possible. WebKit manages to do this. On the subject of QtWebKit, one part that is moderately important to Webkit is partial updates, which really only work in the QWidget interface but not the QGraphicsWidget interface.

Quote:
So just because you don't like Qt, you say nobody should use it? I bow before the great dictator. Now do you want to start comparing Qt's API against Java's?
I did not say that, did you read the last blab I wrote, "I would like to see Qt fixed"? Sarcasm does not help anyone here. The point I am wishing to make is that Qt's deletion on the surface attempts to let one "delete and not worry" as in an garbage collector language, bun in Qt one cannot it to work as well. In garbage collected languages, such languages do much of what Qt attempts to do and better. As I've said, on the surface it looks all rosy, but down the road nasty, ugly things happen.

Quote:
I would say: it does a lot of things, and a lot of them better than others, in a consistent and platform independent manner. Good luck in finding other open source components that do the same things better, more consistent, interoperable, better documented, and work on all those platforms. And of course, developers should be more productive with those.
Name some bits that Qt does better. An ideal world would be where the API's use standard STL to interface, simple and direct without reinventing the wheel for each API, interchangeable too. Calling using STL complicated is not at all accurate. Additionally, STL and boost provide a platform agnostic API, to give an idea of how tricky that really is, and how far Qt has to go to match boost, take a look at boost's file API. That Qt has it's own container classes rather than using STL's is serious shortcoming.

Quote:
You're not going to say that gtk-- (why do you think they name it *minus* instead of plus?) is a superior widget set than Qt, do you? And, sorry, a C widget library is not state of the art anymore. We're in 2010 by now.
Yes it is 2010 now. In Qt embedded classes are not possible due to moc and a variety of other restrictions not present in C++. It is 2010 and Qt's container classes are a throw back from the early 90's, at best. Look into boost and we see lots of goodies: adaptors, lambda calculate, compile time template optimization, etc.

If we are to take this one step further: write a paintEvent function, watch it crawl and block. In a modern system the painting would be done on a GPU (or separate thread) to parallelize. Not in Qt: all in one core, using more cores one needs to do so by hand (through a Qt API no less)! Then you say that I lie, there is the GL backend, except it is a throwback piece of garbage too. The painting API of QPainter is a throwback to the late 80's and early 90s'. Saying "and, sorry, a C widget library is not state of the art anymore." is just silly. Plenty of people will say the same thing of C++. Some will pound for Objective C and C++, others Java, others for other languages, the list goes on.

Here is a question for you: Using GTK/GDK's C++ interface how is that not as modern as Qt? Saying that it is C underneath is not a reason, we all know this. A big failing of Qt is that it does not use the capabilities of C++ compilers that have been present for over 5 years.

Also, in truth GTK's widget set is better: each widget has a specific purpose and is clearer to use. Qt's widgets and classes more often than not have a great deal number of flags whose precise effects are poorly(at best) documented, when one gets into the interaction of such flags the only real hope is to open Qt source code.

The other terrible failing is what and how Qt wraps, lets take GL: http://doc.trolltech.com/4.7-snapshot/qglshader.html from a 4.7 snashot. Couple observations: no support for tesselation, no support for GL 3.2 geometry shaders. Guess what: the geometry shader API under Qt for desktop is actually NVIDIA only. ATI does geometry shaders via the GL 3.2 interface. Lets go further here: no support for uniform buffer objects, no support for unnormalized integer attributes, infact in thr Qt API only support for float and vecN attributes. Essentially, almost any feature introduced in GL3 is not exposed in the Qt interface. Damn, not even MRT which is from GL 2.x. Over in QGLContext: http://doc.trolltech.com/4.7-snapshot/qglcontext.html we see some fail here too. No support for core vs compatibility profiles, no concept of OpenVG context. The list goes on and on. One can almost pick an API wrapper and begin the listing the shortcomings strongly. An intelligent design would have been to provide adaptors to feed into those API's rather than attempting to wrap the API itself.

Quote:
Re: GTK/GDK) How can you use GTK without GDK? You can't. Or is your point that you can use GDK without GTK? How many applications actually do this? Are those additional widget sets and libraries abstracted so that you may plug in different implementations? Not that I know of. Qt is extended by lots of third-party modules, heck, all of KDE. So no point here.
Here are some awful catches: what license are those third party modules? Outside of KDE, how many of them are mainstream? How many of those libraries are backed by more than just a few developers? Once we cull those out, for a commercial application one is left with: if you use Qt, just use Qt as from Trolltech. Not the case for GTK/GDK. Also, that GTK and GDK are separate is an example of how much better GTK/GDK are modularized.

Quote:
Re documentation) Are you suggesting that gtk is better documented than Qt? I hope not. Qt is one of the best documented library, please have a look at http://doc.qt.nokia.com/latest/index.html
Now that is rich as that is the first place I go to see what something means. Here lets give an example: http://doc.qt.nokia.com/latest/qfont...eStrategy-enum :

"QFont::OpenGLCompatible 0x0200 forces the use of OpenGL compatible fonts."

What does OpenGL compatible font mean? A bit map font only? Are such font's only rendered as cached textured glyphs? Cannot tell at all from the documentation. One must open up the source code.

Here is a little test, find the answers to each of the following question using only Qt docs and not Qt source code: Under what circumstances does a QGLWidget permit partial updating? Does it work in the EGL world too? Does partial rendering work if I attach a GL context myself to a QWidget? Can I even do this? What buffers of GL are affected by QPainter? (this question is particularly important if one wished to overlay over a 3D scene) If I create another thread and use a QWidget as the device for a QPainter, under what conditions can I do this? Try finding the answers of these in the documentation only. Notice that this is JUST GL an drawing to Qt. Pick a wrapper that Qt has, and more questions than the documentation come up.

More thorough documentation than Qt are abound:

Open API examples:
1) OpenGL specifications
2) OpenCL
3) OpenMAX
4) OpenKODE
5) OpenSL
6) OpenWF

Proprietary examples:
1) MS-Windows at MSDN
2) Apple API at Apple developer site (both Mac OS-X and iPhone/iPod/iPad).

Each of these is orders of magnitude better documented than Qt. The only place where Qt can win is that I can inspect the source to see how it uses the underlying platform, that is not documentation and such information may or may not change from release to release.

Oh yeh, GTK and GDK are very well documented: http://library.gnome.org/devel/references . Also note that navigating it is significantly easier that Qt doc navigation and for that matter: http://www.gtkmm.org/en/documentation.html. One really nice bit on the GTK side, each widget has a very, very specific purpose, one does not need to deal with all the flags of Qt and worry about how they interact. Another really nice bit: GTK leverages existing libraries, these libraries improve and add API points, one can make immediate use in one's GTK/GDK code. Qt is a monolothic and cannot compete here at all. By the way I am not suggesting GTK and GDK are better documented, I am saying they are. They leverage public libraries and each widget has a simple purpose it does and does well.


Quote:
You know the git repository, don't you?
Sighs. More sarcasm. Lashing out at me does not help Qt. Just so you know, I do know the repo, I regularly clone from it. Awfully painful at times to find a version that builds.

Quote:
Maybe your definition of fine is not the same as that of others. Maybe you mix up "fine" and "perfect". Maybe Qt is not perfect on embedded devices.
I am not going for perfection at all, I am looking to leverage what every modern (read no more than 7 years old) C++ compiler provides, use existing libraries and their extensions and to minimize unpleasant surprises as soon as possible. There are not very lofty goals. Qt poorly leverages C++. Qt makes no public leverage of other libraries. Qt has a great deal of unpleasant surprises.

Quote:
So there's a chance to improve it! Looking forward to your patches and input.
I have no interest whatsover in doing someone else's job for free. I patch Qt internally for the projects and my employer (or really the customer) makes such patches public. If you are serious and have authority, PM me and we can work out a contract for me to improve Qt.

Last edited by kRogue; 07-26-10 at 03:30 PM.
kRogue is offline   Reply With Quote