On 10/07/2011 07:29 PM, ext Till Oliver Knoll wrote: > Hello Thiago, hello everyone, > > I read all messages so far to this subject, but will reply to Thiago's > message only for now. It kind of sums it up anyway very nicely. > > 2011/10/7 Thiago Macieira<thi...@kde.org>: >>> ... >>> 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. So in the worst >> >> That's where you got it wrong. The QWidget implementation does not sit on top >> of the QML-based Scene Graph. It still uses the old backing store, to the >> point that there is a class called QBackingStore. The QWidget architecture is >> mostly unchanged. > > Okay then, glad I misinterpreted this. As Thomas already mentioned, I > had exactly this article in mind: > > http://labs.qt.nokia.com/2011/05/09/thoughts-about-qt-5/ > > May I quote that specific paragraph: > > "QPainter will still be available and is very useful for many things, > but it won’t be used for the main user interface. Qt will require > OpenGL (ES) 2.0 to work. QWidgets will be layered on top of the scene > graph (not the scene graph on top of QWidgets as is currently done > with Qt 4)." > > Now you tell me that QWidgets won't sit on top of the scene graph > (which requires OpenGL ES etc.) and I take your word for it. My > interpretation was different and based on that assumption my > impression was that in Qt 5 the "QWidget stack" would be merely put on > top of the new scene graph, dropping the "QPainter" approach > altogether - with all the necessary additional libraries.
Yep, we were considering different options. In the end QWindow supports both QPainter based rendering with QBackingStore and OpenGL based rendering with QOpenGLContext. >>> I chose Qt as a C++ framework for a reason! ... >> Because it's easier to use? Because designers can design the UI, instead of >> engineers? There are many reasons to use it. >> >> The fact that technologies like Python exist prove that there is a need for a >> simpler way of developing things. > > Yes. Might be true for small applications, "weather apps" and sort of. > >> Ok, then you want OpenGL. You said you wanted performance, therefore you want >> OpenGL for your UI. > > No. I want OpenGL to render MY stuff, and not getting into my way when > rendering the GUI. > > I already mentioned that I am fully aware that these days window > managers such as on Mac OS X, Windows 7 (Vista) also use OpenGL. But > first off that's on an "OS level", that is highly optimised, whereas > the OpenGL rendering of Qt would be "on top of that", in "application > land". The window manager would have no influence on optimising that > (which I hope it does when painting its own widgets). > > Well anyway, my point is that performance for drawing a few buttons > and rectangles is way enough available these days! Heck, we're talking > GIGAHertz these days, not Megahertz! > > And updating the GUI in Qt was never a bottleneck for me. > > Again, I am talking about "plain old desktop applications", with the > look and feel of the underlying OS. QPainter on Linux is using Xlib and Xrender, which was probably still accelerated by the GPU to some degree (pixmap blits, text rendering, etc). It's just that a lot of operations weren't supported so we have to fall back to QImage and do an expensive pixmap / texture upload. Thus, both the CPU and GPU are not really being used in the most efficient manner. It turned out that Xlib and Xrender was lacking as an abstraction for what the GPU is capable of, which is why we moved toward doing most of the rendering to a QImage and instead doing controlled uploads of the dirty areas of the window surface in the end, faster than having to read back data from a pixmap, do the rendering to a QImage, and re-upload the QImage for blending for individual paint commands. Still, using OpenGL efficiently is better for CPU (not a lot of rendering done there) and GPU usage (not doing a lot of texture uploads all the time). That's what the scene graph enables us to do. OpenGL is becoming ubiquitous these days, it's time to take full advantage of it. Since scene graph is using the GPU in a better way than traditional widgets, I doubt it would steal any performance from your more demanding OpenGL applications. >>> ... each time the GPU >>> starts cooking, simply because I resize my main window! >> >> Yes. Fortunately, your GPU will be burning less battery power than the >> equivalent operation on the CPU. So you have a net gain in battery >> consumption. > > ... under the assumption that the CPU is using less or no power at all > in the meantime. Besides graphic performance is accelerated since > Window 3.1, for instance no CPU is wasting CPU cycles when drawing a > rectangle or a line! That's all being handled by dedicated chips on > the normal 2D graphic card, and the same argument with less power also > applies there I guess. > > So no, I don't think that using your GPU would actually consume LESS > power than the combination CPU/2D graphic card. But let's not count > watts here either ;) I think most GPUs don't separate too much between the 2D and 3D rendering these days, when it comes to rendering gradients and blitting / scaling pixmaps it's the same thing. >>> - I want native widgets! >>> >>> I want my application to look as natively as possible! >> >> You're calling for two separate things there. You want either native, or you >> want no drop shadows and no rounded corners. If the native widgets have them, >> asking not to have them means having non-native widgets. > > No, my point is a different one: I want native look and feel! If the > native window manager decides to draw a nice shadow around every > dialog, then so be it! If the native window manager decides to draw > rounded corners around my main window - so be it! So I was NOT asking > for "no, I don't want to have drop-shadows or rounded corners", I was > asking to have widgets which EXACTLY (as closely as possible at least) > behave like the underlying window manager/OS would do! (And you can > extend this to anything beyond drop-shadows and rounded corners: > colour schemes, click-behaviour etc.) QWidgets weren't really able to produce perfectly native look and feel on Mac OS X. And scene graph items shouldn't be _less_ capable that QWidgets, as long as the theme data ends up in a texture somehow. The desktop components for QML already wrap the native style APIs. > Agreed, animating stuff, drawing custom widgets etc. is indeed much > easier in QML. But to repeat: I don't want to animate, I don't want > custom widgets (and I am talking about the "ordinary" and typical user > interface elements such as buttons, comboboxes, not about "custom > widgets" such as graphs, stock tickers or what not). > > So all this doesn't bring me any value. It's not necessarily about glaring animations, rather of subtle fading etc (which granted can be done with QWidgets as well, but in a way that's less easy to experiment with and tweak for a designer). See the YouTube video in this blog post to see the possibilities: http://labs.qt.nokia.com/2011/03/10/qml-components-for-desktop/ > But for God's sake, don't let them near any coding of the user > interface! Don't let them think that if they were able to code some > website that they would do any good with "custom buttons", animating > windows and stuff and then you stumble over UI items not being > properly disabled/enabled, texts cut off because "Ups, the german > sentence is longer than the english one - but hey, we HAVE to have a > fixed size button here, because otherwise the texture wouldn't cover > the entire background"... There needs to be interaction between the UI designer and the developer. QML simplifies that interaction :) > No we can't. But also remember that the trend in UI is now in the > OTHER direction again, towards SIMPLER and MINIMALISTIC ways of > drawing stuff, see Mac OS X! The time of "Hey, KDE can draw wobbly > wobbly dialogs (but requires OpenGL support to do so)" is long time > over! > > And Qt just performs fine (with QWidgets!) on todays hardware, so why worry? We're not talking wobbly dialogs here, rather subtle and refined transition effects and highlighting etc. >>> Thanks for those who actually read until here, and apologise again to >>> those who skipped reading long time ago. ;) >>> >> Unfortunately, you lost time writing all of that based on mistaken >> assumptions. If you had just taken the time to clarify first... > > No, my point still stands: as long as I can code with Qt 5 without > touching any JavaScript/QML if I don't want to, I am perfectly happy! > I had reasons to believe that I would not be able to do so, but you > said otherwise. I have to take your word for that. You won't have to, unless you change your mind in 5.1, 5.2, or later, and want to give scene graph another chance. -- Samuel _______________________________________________ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback