On 4/22/2021 4:50 AM, Volker Hilsheimer wrote: ....
* imperative painting Paint-event based drawing with a “pen” is not easily reconcilable with how GPUs like to work. Without a persistent scene graph that is uploaded to the GPU, much of the performance you get from a GPU islost. An animation at 60fps is ideally just a draw call on the GPU with some different transformations, not a completely new upload of a completely reconstructed scene graph for each frame. Widgets can draw into a framebuffer texture that can be used, and that allows for some integration, but that doesn’t give you great performance.
Why can't "Widgets" be drawn the same way QtQuickItems are drawn? As an alternative to pen/brush, or direct GL calls. Just like there's a QtQuickPaintedItem alternative. Essentially it's just another way to paint a widget (or whatever!)... or am I missing something? What is a QtQuick Control if not a type of widget?
If you mean batched render of all items in a scene, isn't that a function of the scene? Or partial redraw of only changed region, or for that matter only applying a transform if that's all that has changed. Ideally widgets shouldn't even care what kind of scene they're being drawn into, but at worst they could be aware and adjust accordingly? I'm sure I'm oversimplifying and generalizing here. I've read (or tried to) a number of Qt contributor publications on the matter, trying to understand, but they typically all start with some bullet points on why QPainter is "bad" and why it needs to be thrown out, and go from there (or just dive into how great the new system is) w/out any real alternative analysis. Many also seem to assume that "mobile" devices (or "embedding") are the only ones of interest anymore, or at least that's my impression.
* integer coordinates and clipping Widgets work with integer coordinates, which starts to be problematic now that we have high-DPI displays. And widgets clip are clipped to their parent geometry, which was the right choice for those UIs, but is very limiting and requires a lot of complex code to solve conceptually simple problems. Hello macOS focus ring. Quick items do not clip and are not clipped, which gives a lot more freedom in how shapes are combined and structured.
Err... Qt Graphics Framework? And GL windows where developer can do whatever they want? There is (or was) even a note somewhere in the GF docs about how this may become the future QWidgets underlying framework. That's all pretty much been abandoned, which is unfortunate because there's a lot to like in there, including native widgets and nice layouts. And it is very performant.
Within QWidgets one can already draw in floating point coordinates. Granted most existing QWidgets don't, but they could. I have a test app with 10+ animations of various sizes in one window, using QPainter fp drawing inside QWidgets, running 25+ fps on a little Pi Zero from 2017 pushing a FHD display.
And applications written with either of those "outdated" technologies actually run fine on phones (Android anyway, never got around to the other more crippled OS)... it's just that you pretty much need to draw them yourself right now, or at least heavily customize. I wrote a fully animated touch-friendly "airplane HUD" type application using Graphics Framework, 5 years ago now, using all custom-drawn controls, SVG graphics, and moving maps, pulling live data via radio link from a UAV, and it ran fine on decently powered phones/tablets of that time. Zero QML, 99.9% same code for all platforms (not counting build/packaging scripts!).
So yea, I don't really "buy" this "we had to re-invent the wheel to make it more efficient." I do get wanting a new shiny carbon fiber wheel. Just too bad the old but mature wheels get no real love.
* declarative vs imperative APIs Many widget classes don’t have a declarative-friendly API. Plenty of widget properties have side effects on other properties, so the order in which properties are set matters. That doesn’t work well ina declarative world.
Well this sounds like a major generalization on several levels and I'm not going into all that, but even if the statement were entirely correct, this just means another set of widgets which don't care which order properties are set in... or an abstraction layer over existing widgets. And yea as mentioned already... what is QtDesigner XML then?
* weight Widgets are heavy, often very complex objects. They often come with allbells and whistles. QPushButton always has the data structure to support QPushButton::setMenu, even if probably <1% of buttons out there ever usethat feature. That’s ok on desktop machines, it’s not okon embedded systems.
So QML components are stripped down to the bare minimum functionality that someone decided was good enough? That does indeed echo some of my frustration with the relative immaturity of QtQuick controls.
Or is, say, a QtQuick backend C++ button object less complex than using a QWdiget one? Assuming they both had the same features. I can see how one could start from scratch and create a simpler version, sure... maybe optimize some legacy code, sure. But ultimately they'd both have to do the same logic and drawing steps behind the scenes. I don't see how one would be "lighter" somehow in the end. If it has fewer features... sure.
The obvious answer to your particular example is to use QAbstractButton and build up. It already has almost all the same functionality as QPushButton, w/out the objectionable menu. Hooray for abstraction and inheritance!
* complexity and hard to customize Inheritance and reimplementing are nice concepts on paper and works great if you build your own custom widget from a reasonably abstract base class. But if you have ever tried to subclass e.g. QTreeWidget to modify how certain interactions work, then you know how hard it can be to not break the complex states that the default implementations rely on.
Maybe it's "complicated" if one is coming from JavaScript of 10 years ago, but um... no, can't agree at all. Inheritance and re-implementing is f'ing awesome. It is so ironic to hear you say that because my biggest frustration with QtQuick Controls 2 was the absolutely inane "inheritance" model where each theme needs to be re-implemented separately... with NO access to the underlying C++ objects where customizing functionality would be, in most cases, far, far easier. But, sorry, the whole theming system is ridiculously implemented in regards to QQC2. To me this breaks much of the point of having "themes" in the first place, which would presumably need to vary from device to device or based on user preference. In Q[Graphics]Widgets the theme can be switched much easier. And don't get me started on the irony of not being able to use CSS in QML.
As for "embedding"... Embedding into what? This term gets thrown around a lot and is again a huge generalization. One could "embed" firm/software into pretty much anything these days. It may or may not have a GPU. Do you mean integrate with an RTOS? That would require some serious analysis on the part of the implementer IMHO, not just QtC saying "it works great." I'm not running Qt on my UAVs or radio controllers, I can tell you that.
And honestly... QTreeWidget as the example? NVM that nothing in QtQuick even comes close to everything one can do with that, somewhat bloated/gross, smashup of models and views into one deceptively-simple-to-start-with object. Or QTreeView for that matter (which yes I do re-implement quite often, even if it's for just a quick painter tweak in one virtual method). But there are plenty of better examples which are absolutely meant to be re-implemented, starting with the ones that have "Abstract" in their names (something QQC2 seems to be desperately missing). I often wish more methods were virtual in higher level widgets, but I understand why conservatism is good in that regard.
So, making widgets work in a declarative, GPU friendly world where easeof customisation is more important than standard look’n'feel would have required many changes to widgets. Those would have been impossible to make without invalidating or breaking a lot of code out there, and still not given us the UI components we would have needed.
Again I think QQC2 completely missed the mark as far as "ease of customization," in fact all you're apparently meant to customize IS the look'n'feel in each theme... so not sure what kind of customizing you mean there.
Anyway, so far I haven't heard a convincing argument on why any of the drawing performance improvements couldn't have been implemented in "QWidgets" or Graphics Framework. Then possibly they could be re-used in QML. And/or have new "skinny" optimized QtQuick widgets built (the way they are now anyway), which could then also be used in either language/framework. Or even, yeah, why is it "impossible"/hard to just use the QtQuickItems directly from C++ (as brought up on this thread I think)?
I really did want to like QML to bridge the "gap" to the phone/tablet UI, and the language and syntax and all that is fine, but in the end I was very frustrated by the limited widget functionality and the difficulty in customizing them (search for my MLDoubleSpinBox on GitHub for an example of how ridiculous it can get to do so). I decided it's easier to just write HTML/JS/CSS for the UI... with all of the zillions of components already out there for it and support on basically any device I'd be targeting with a rich 'universal" UI anyway (and could still keep Qt backend which has pretty much everything to inject data into JS structs/objects/vars). Seems maybe Qt was headed this way at one point as well, but also nixed... too bad. But for "real desktop" (pointer+keyboard) Qt applications with a bunch of controls and windows or whatnot, QWidgets and Graphics Framework are still best IMHO, and can even work fine on Android or small "single board" computers as well if properly managed and run on modern (last 5-6 yrs) hardware.
Cheers, -Max _______________________________________________ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
