Go Back   nV News Forums > Linux Support Forums > NVIDIA Linux

Newegg Daily Deals

Reply
 
Thread Tools
Old 07-21-10, 12:19 PM   #25
miki100
Registered User
 
miki100's Avatar
 
Join Date: Jan 2009
Posts: 10
Default Re: is the nvidia driver falling behind?

With faster I meant "faster than default settings" and with slow "slower than other desktop environments".
__________________
Gigabyte GA-8I848P-G; Pentium IV Prescott 3,0GHz@3,2GHz; 2GB RAM, Galaxy Geforce 7600GS, Sound Blaster Audigy
miki100 is offline   Reply With Quote
Old 07-21-10, 12:55 PM   #26
plun
Registered User
 
Join Date: Jan 2007
Posts: 30
Default Re: is the nvidia driver falling behind?

Quote:
Originally Posted by hl_ View Post
Yes. I know KMS or Gallium are more than buzzwords, but they're often used as buzzwords, like they are some kind of magic fairy dust.

"You have to implement KMS/Gallium... because... well, it's the newest ****!"
Hehe.....

I don't know what good KMS brings ? is it useful for anything a normal user needs ?...... is it an Intel-trick for selling crappy graphic-cards..?
plun is offline   Reply With Quote
Old 07-21-10, 02:47 PM   #27
kRogue
Registered User
 
Join Date: Jan 2005
Posts: 19
Default Re: is the nvidia driver falling behind?

I just wanted for everyone to know what raster means in Qt along with the other graphicssystem parameters:

Native: for X11, means XRender (usually).

raster: means all drawing is done to main memory by the CPU... more or less it equivalent to drawing to a QImage and then drawing the QImage to the screen.

opengl: use GL1 or GL2 backend with preference to GL2 backend.

Now, Qt gets better performance from raster, which strongly implies one of the two (or both) of the following:

1) QPainter API maps poorly to XRender

or/and

2) Qt XRender backend has issues in terms of how it works.


What is truly frightening is that Qt graphics does perform so poorly, the majority of the use patterns for QPainter are drawing the same stuff to screen that has been drawn to GUI for over 10 years (really even more).

I remember years ago about the flame war of that KDE uses Qt... and then later came the "QPL"... in truth the flame war completely missed many of the technical points. One more note on KDE4: it has only been since October or so that KDE4 used Qt 4.6... AFAIK, and someone correct me if I am wrong if you are using KDE4.3 or older it is at best linked against Qt 4.5.x... and guess what people: GL backend of Qt 4.5.x is horrifyingly bad.

For UI tool kits, in the Qt vs GTK/GDK, GTK/GDK are really the way to go, they are better modularized, have C and C++ interfaces and a much better internals than Qt.
kRogue is offline   Reply With Quote
Old 07-21-10, 03:14 PM   #28
wantilles
Registered User
 
Join Date: Feb 2009
Posts: 37
Default Re: is the nvidia driver falling behind?

Quote:
Originally Posted by kRogue View Post
For UI tool kits, in the Qt vs GTK/GDK, GTK/GDK are really the way to go, they are better modularized, have C and C++ interfaces and a much better internals than Qt.
I was under the impression that the exact opposite is true.

Quote:
Originally Posted by kRogue View Post
...and guess what people: GL backend of Qt 4.5.x is horrifyingly bad.
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?
wantilles is offline   Reply With Quote
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
Old 07-21-10, 06:38 PM   #30
ubersoft
Registered User
 
Join Date: Jan 2009
Posts: 6
Default Re: is the nvidia driver falling behind?

Whoever posted that support for multiple monitors is "rarely used" is working from outdated information. At my office it is the norm, not the exception (but Linux isn't intended for business use!) and I want to be able to replicate it in my home office (but Linux isn't intended for home use!) (then why are we all here?)

I have nothing to add to the technical discussion about QT, other than to state that I use KDE 4.5 and I prefer it over gnome, so any explanation about how poor the qt implementation of whatever is, is ultimately meaningless for me -- as mentioned in other posts, ATI and Intel drivers handle KDE4 just fine and long-winded explanations about how nvidia shouldn't have to work around shoddy software implementations overlooks pretty much the entire history of the various and sundry flavors of the Windows operating system.
ubersoft is offline   Reply With Quote
Old 07-23-10, 05:06 AM   #31
gisl
Registered User
 
Join Date: Jul 2010
Posts: 6
Default Re: is the nvidia driver falling behind?

Quote:
Originally Posted by kRogue View Post
After dealing with the internals of Qt I have enough personal experience to say GTK/GDK is better. Here are a few reasons:
You ranted a lot about Qt, but didn't give a single argument in favor of GTK/GDK. Even more, for some of those "issues", there is not even an equivalent in GTK.

Qt's container classes exist since before STL was widely available and usable.
You are encouraged to pass objects by const reference, nobody prevents your from doing this. But even if you pass the object by value, you save cpu and memory, because the container does the copy on write.

Re: Javascript) Is GTK's Javascript engine faster? Oh wait, there is none.

Re: MOC) moc provides way more features than RTTI.

Re: signals and slots)
- the dynamicity allows for introspection and to invoke slots dynamically, e.g. through dbus calls
- e.g. KDevelop provides static analysis to spot connect() errors

I won't comment on your other rants.

Cheers.
gisl is offline   Reply With Quote
Old 07-23-10, 10:42 AM   #32
kRogue
Registered User
 
Join Date: Jan 2005
Posts: 19
Default Re: is the nvidia driver falling behind?

Quote:
You are encouraged to pass objects by const reference, nobody prevents your from doing this. But even if you pass the object by value, you save cpu and memory, because the container does the copy on write.
You ARE NOT encouraged to pass container objects by const reference. Give you a hint, find a public API function in Qt that accepts a constant reference to a Qt container class, same goes for QImage and QPixmap and many others.

There is a big horrible stinking issue with this copy on write business:
1) I cannot tell from a function declaration if a copy does happen, this is horrifyingly bad. I cannot tell from a function declaration at all. Care about performance you care about this a great deal.
2) If I fetch a read only pointer from a Qt container class, save that, and then modify the contents of the Qt container the pointer is not correct. At first such a use case seems artificial but it rears it's ugly head a great deal. This is an issue when using GL, and the Qt GL code has this. QImage using in Qt source looks even funkier, but it is the way it is because of this pass by value-copy-on-write business of Qt. Qt's API is almost all pass by value where as pass by constant reference is the way it should have been.

I would not mind Qt's containter class if the Qt API would accept STL containers, but it does not, at all. Thus to use the Qt API you need to use Qt's container classes which are pretty poor. That Qt started before STL and RTTI(for moc) before they were reliable is a historical reason. That does not change the fact that they are inferior. Worse, STL and RTTI have been reliable for atleast, what, 8 years atleast, plenty of time to replace the Qt container classes with STL ones.

Quote:
Javascript) Is GTK's Javascript engine faster? Oh wait, there is none.
Exactly, you can choose your javascript. In Qt you MUST use Qt Javascript which is nowadays one of the worse Javascripts around. Sadly, one of Qt's most promising components QML must use Qt Javascript and that will hurt QML's performance, particularly in embedded devices where much of the action is nowadays. Oh wait. Qt's drawing sucks too. The lack of modularity inside of Qt makes it impossible to replace a poor component with a better one.

Quote:
- e.g. KDevelop provides static analysis to spot connect() errors
Wonderful, to pick up an error that the compiler should pick up I have to use a particular IDE. No dice.

Quote:
Re: MOC) moc provides way more features than RTTI.
List the features is provides, please do. While listing them think about what it is and how there are better ways to do each of them. At the very least, list them, and I will then tell you.

I suppose you might be referring to this from Qt: http://doc.trolltech.com/4.6/templates.html among other bits.

Let me diagnose the failures here, ok.

Firstly adding member functions, or for that matter virtual member functions does not increase the size of an instance of a object in C++ once that object already has virtual member functions.

There are other amazing lines such as this beauty:
Quote:
"And we can have overloaded signals and slots, which feels natural when programming in a language where overloads are a key concept. "
Priceless. sigc++, boost signals all handle overloaded function calls.

Other bits:
Quote:
Another benefit is that we can explore an object's signals and slots at runtime. We can establish connections using type-safe call-by-name, without having to know the exact types of the objects we are connecting.
The line of not knowing the exact types, is rich. Can anyone say "base class and virtual methods" Now you can make a case: get function name by string name. This lets you not have the header file to the classes you are connecting. You can also make the case that being able to list the slots and signals of a class at run time and then conneting them. Alas, there are better ways to do this than Qt's system. Much better ways.

The richest sections of that is "Calling Performance is Not Everything". Plenty of signal libraries (such as sigc++ and boost:signal2 do marshalling and all that Qt's object system provides WITHOUT requiring a tool to execute on C++ source code to produce more C++ source code). Oh and runs more efficiently.

Another point is that if you had deleted an object at the other side of a connection, you don't have to worry about a crash from calling a function on a freed object. Epic fail. They have traded a crash for a host of harder to track down object. "I did connect that signal to foo's which connect bar's slot, why is not bar's slot getting called? Oh someone, somewhere deleted foo" The big failure here is that Qt has essentially a broken quasi-garbage collector. It sort of deletes children of objects correctly and calls disconnect for you, but it introduces a great deal of unpleasant surprises.

As they talk about their qdymamic_cast<>, it starts to look even worse.

One point that they totally missed: they added moc to get around C++ deficiencies of over 10 years ago. The need for moc has not existed since g++ 3.x. Another very creepy part: the attitude of trying to provide lots of programming safety in C++, they don't like iterators and more. They miss the point: if you want lots of safety choose a "managed language" such as Java, or many others. The safety provided by Qt is only skin deep and trades crashes for more subtle and harder to diagnose bugs.

One amazing point of honesty that made was that objective C is great, and get this people: Objective C code doing what Qt's signal/slot code does is about 5-10 times more efficient and more flexible. Sighs.

Quote:
You ranted a lot about Qt, but didn't give a single argument in favor of GTK/GDK. Even more, for some of those "issues", there is not even an equivalent in GTK.
Lets first address a serious issue with Qt, that I stated before: it does many things, but many of those it does very poorly, I would be kind in saying it is a jack of many trades and master of none. Now onto GTK/GDK:
1) Notice GTK and GDK: there is a separate library for separate purposes, moreover GTK/GDK has additional widget libraries with specific purposes. Qt does not. Along the same lines GTK/GDK leverages libraries that are for very specific purposes. In contrast, Qt mostly does not or attempts to completely hide such.

2) With GTK/GDK there is a C interface and a C++ interface through gtkmm, etc. Qt is C++ only AND it is a deviant form of C++ at that.

3) QWidgets and QGraphicsWidgets have many, many flags; in contrast GTK/GDK do not. This is a good thing. Many of the flags for QWidgets and QGraphicsWidgets are poorly documented and their interactions as well. As such, to really see what is going on one has to open up Qt source code. GTK/GDK widgets have no way near as many flags or surprises in using them.

One point that you are completely missing, which to some degree is one of the big points of Unix: make a simple tool or library that does one "thing" and does it well. Qt does many things, and none of them very well. For each component of Qt there are much better alternatives. GTK/GDK gives more options, and oh yes, performs better.

There are so many better tools and ways to accomplish what Qt attempts to do, these ways being faster, more stable, fewer surprises and *ahem* better documented than reading Qt source code.

I would like to see Qt fixed, particularly the drawing stack. However, it is not a matter of fixing so much as re-doing. The Qt containers should be dumped. The internals of Qt need a horrible cleaning up to be better modularized. Qt as a whole needs to be better modularized so that poor performing components can be removed and replaced with better, already existing solutions. Qt layer to such is fine and acceptable. However pretending that Qt is just fine is not acceptable. Put Qt on an embedded device and watch the poor thing crawl. Embedded devices are where the action and future of open source consumer goods are located.
kRogue is offline   Reply With Quote

Old 07-23-10, 04:46 PM   #33
gisl
Registered User
 
Join Date: Jul 2010
Posts: 6
Default Re: is the nvidia driver falling behind?

Quote:
Originally Posted by kRogue View Post
You ARE NOT encouraged to pass container objects by const reference. Give you a hint, find a public API function in Qt that accepts a constant reference to a Qt container class, same goes for QImage and QPixmap and many others.
Here's one by-reference for you:
http://doc.qt.nokia.com/latest/qtext...xtraSelections
And believe me, there are more.

Re:1) All you need to know is which classes implemented are implicitly shared.
If a method actually takes a parameter by value you can assume that it is slow (because it copies). If it isn't slow because of implict sharing, the better! If you are worried about that, because you want performance, you check whether that class is shared. If it isn't shared, well, then it might indeed be slow, so your assumption was right.

Re: 2) do I understand you correct, that you pass something by value and expect it to not be copied?

Qt's container classes can be mixed with STL containers, so your pain should not be that bad. And I know a lot of people who prefer Qt's container classes over STL. STL may be more powerful, but also way more complex.

Re: Javascript engine) are you proposing to write an abstract interface for different javascript engines? How much sense would that make? There isn't even a DOM interface you could share, AFAIK.

I suppose it's much easier to improve Qt's Javascript engine than integrate different engines.

Re: moc) I already provided them in an earlier post.
You can always debate over advantages of different implementations. And if you already have one implementation, you weigh the cost of switching that one implementation with the other against the benefit that the other would bring. If the benefit is not worth the cost, you don't switch.

Re: deletion and disconnecting of QObject children
I'm afraid this is just your own opinion that this is a bad idea.

Quote:
They miss the point: if you want lots of safety choose a "managed language" such as Java, or many others. The safety provided by Qt is only skin deep and trades crashes for more subtle and harder to diagnose bugs.
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?

Quote:
it does many things, but many of those it does very poorly, I would be kind in saying it is a jack of many trades and master of none.
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.

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.

Quote:
With GTK/GDK there is a C interface and a C++ interface through gtkmm, etc. Qt is C++ only AND it is a deviant form of C++ at that.
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.

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

Quote:
I would like to see Qt fixed
You know the git repository, don't you?

Quote:
However pretending that Qt is just fine is not acceptable. Put Qt on an embedded device and watch the poor thing crawl.
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. So there's a chance to improve it! Looking forward to your patches and input.

PS: I'm afraid we're getting slightly off-topic for an nvidia forum.

Cheers.
gisl is offline   Reply With Quote
Old 07-23-10, 06:22 PM   #34
Sean_W
Registered User
 
Sean_W's Avatar
 
Join Date: Jun 2007
Posts: 2,423
Default Re: is the nvidia driver falling behind?

Well, a lot of the KDE people blamed NVIDIA for their slow 2D performance. The thing is, it wasn't only down to NVIDIA.

Qt dropped to to slower rendering in certain situations. The Oxygen window boarder has a performance bug which makes KDE4 laggy. Honestly, newer KDE4 versions are worse with laggy window resizing and general usage and not purely because of the NVIDIA binary driver.

One of the worst apps for this is Amarok2. The redraw speed is terrible on resize and reaction for the systemtray. Scrolling in a playlist is horrible.

Last edited by Sean_W; 07-24-10 at 04:28 AM. Reason: typo
Sean_W is offline   Reply With Quote
Old 07-24-10, 01: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 02:30 PM.
kRogue is offline   Reply With Quote
Reply


Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


All times are GMT -5. The time now is 08:05 PM.


Powered by vBulletin® Version 3.7.1
Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Copyright 1998 - 2014, nV News.