On Friday 07 October 2011 14:27:20 Till Oliver Knoll wrote: [...] > But recently it turned out that the whole paint stack, the "scene > graph", will be completely rewritten, to favour the QML architecture.
The scene graph is a technology that has been writen specifically for QML, If you want to use it, you indeed need QML. But QPainter and QWidget stays there, and are not that bad. (QWidget can't use the scene graph because it has been designed for imperative programming (the way QStyle works)) > And it turns out that for all these "fancy effects" we now need OpenGL > support to get any descent performance. And what's more, the whole > QWidget implementation will sit on top of all that. I am not sure you are correct. Don't confuse lighthouse and scene graph. QWindow (the replacement for top level widget) may indeed require OpenGL (to simplify the implementation) > So in the worst case I will have to link against all these JavaScript engine > and what-not libraries, just to display a "Hello World" in a QLineEdit, > implemented as some QML element in the background, interpreted by some > JavaScript engine, rendered by some OpenGL stack... but nicely shaded > maybe (which by the way I don't want at all, as I want my QLineEdit > look exactly as the "native" one!). No, as you stated before, if you do not want Javascript or QML, you don't link to it. There was a huge thread before regarding moving V8 (the javascript engine) to QtCore. But the result of this discussion is that this will not happen. QtV8 stays a separate library, and you don't need to link to it to use your QWidgets > So QWidget has clearly become 2nd class and with regards to performance "we" > have to take what's left for us! At least that is my impression from some > discussions I followed. QWidget has some performence limitations in their design that are not possible to solve. This is why the scenegraph has been developed. And that will not work for QPainter and it's imperative drawing. Now, QWidget do not loose anything, it just stays behind, where it was. > So here are some points I'd like to throw in: > > - I don't want to use any JavaScript in my code! [...] Qt5 is not a problem here. > - I want performance! > > I have tested one of my 4.7.3 Qt applications on a >10 year old HP > laptop running Windows 2000 on a Pentium III 600 MHz, 512 MByte RAM. > Just for the fun of it. And it ran perfectly! The main window resized > smoothly and overall GUI performance was very snappy. I am happy with > this! And that is the benchmark I will refer to when testing any > QWidget application on top of Qt 5. Please try it with the current development branch of Qt5. I see no reason why it would not work anymore. > But with the current requirement that even the QWidget based apps now > need OpenGL support that means I cannot even run my apps in a virtual > machine such as VirtualBox on a Mac in a decent way (and yes, I AM > cross-developing a lot in VirtualBox, for both Windows and Linux)! You should be able to use software randering. (llvmpipe) If you still use the plain widget as before without fancy effect, it should not be slower than the current raster engine. http://labs.qt.nokia.com/2011/05/31/qml-scene-graph-in-master/ > But even from a user perspective (I'd accept the argument that as a > developer I should be able to invest into proper hardware) that means > I am burning battery power of my laptop/tablet/phone each time the GPU > starts cooking, simply because I resize my main window! The GPU is optimized to do draw, it may uses less power than the CPU. > Oh and yes, I also do OpenGL based applications, and I'd hate it to > see the widgets taking away valuable GPU cycles and introducing locks > by GL context-switching, simply because that damn button needs to have > its drop-shadow rendered nicely! (Yes, I am aware that OS X for > instance does nothing else - but Qt would again render ON TOP of that > with its own GL context etc.). I can't answer to that. > - I want native widgets! > > I want my application to look as natively as possible! Native, native, > native! Can't repeat that enough. Even better: Use native widgets > wherever possible (e.g. push buttons, drop-down boxes etc.). No > rounded corners, no drop shadow, no textures where the OS window > manager would not render them anyway! Even with QML, there is some work in the desktop componenent to do exactly that. > - I for sure don't want to hand-code any XML-like GUI files! > > We have Qt Designer for a reason! Editing GUI in a text file is sooo > late century, you know! And if I want to programmatically define the > GUI, then I want it to be blazing fast, means compiled. With a > well-documented API, simple to use. Oh, we already have that, it's > called Qt... > > I wouldn't mind if the Qt Designer would create QML files under the > hood. Much the same way I don't care about the actual content of the > current UI files. As long as I would interface against a compiled C++ > class in my own code! And there's type-safety, and not some "Oh let's > see what that string could be, let's cast it as an int at runtime..." > And if I rename a widget in Qt Designer I want to get a COMPILE error! > And not just a runtime error because the JavaScript/QML interpreter > figured only out by then. QtCreator has an embedded QML visual editor for exactly this purpose. It is still far from being equal to designer, but it is actively developped. > - I want a small memory/disk footprint! [...] Again, i suggest you to try the current snapshot of Qt5 and see the actual problem. Qt5 should be smaller. > I do understand that there is a "research" project on the way to bring > "desktop widgets" to QML. QActions? Oh yes, we need to research that. > Layout managers? Huh... yeah, we thought about that too, needs some > more research. Signals/slots? Menues? Toolbars? Lists? Yes, there is research and it takes time. QML is still very young. Let it mature. > And all this from the C++ without touching ANY JavaScript or wrapper? It is clear that QML will require you to touch JavaScript. But only for simple bindings. > Now to be fair: I have not much experience with QML other than > studying some example code and running it! [...] Now to be fair: your post is a bit long and I stopped reading here :-) But I think your post was based on incorrect asumptions that I hope are clarified. Thanks for your input anyway. _______________________________________________ Qt5-feedback mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
