Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Qt 6.6 and 6.7 Make QML Faster Than Ever: A New Benchmark and Analysis

qt.io

Post reply on HN
Print view View original

21–30 of 107 posts

Re: Qt 6.6 and 6.7 Make QML Faster Than Ever: A New Benchmark and Analysis

#21

Post by lmm »

sourcegrift wrote: post #2

As a Rust user, very happy with qmetaobject-rs. It was really a breeze to make a basic GUI for personal use ... I would also add an opinion: Qt is a great fit for Rust. GUI toolkits (=presentation layer) is best done declaratively and QML does an amazing job at it. Keep in mind that making a GUI kit, specially for 5 platforms in a way that it runs and feels uniformly across them all is a herculean task that returns n…

> even if I can write some GUI in a "rusty" way, it won't suddenly speed up things because GUI is almost never a bottleneck.

Nor are any of the other things people use Rust for, but that doesn't seem to reduce the enthusiasm any.

Re: Qt 6.6 and 6.7 Make QML Faster Than Ever: A New Benchmark and Analysis

#22

Post by self_awareness »

notyoutube wrote: post #9
guappa wrote: post #8

Earlier quoted context omitted.

Could you make some actual example? Because I read 3 paragraph and I have no idea what you're talking about.

I've got a potential example; I always wondered how that would be achieved with something like slint or qml: With tools like xournal++ or other things like document processors, you can usually define your own panels, reorganize them, move them around, add icons or separators, etc, and all of that in a drag&drop fashion, live from the program running. I feel like having a (compile-time) declarative description of that…

Yes, panels are one example. Which panel goes to which window corner? What is the resize policy? It will probably be read from the file according to user preference, so it can't be hardcoded declaratively in QML.

What is the current theme? Window position? Maximized/minimized state? Those need to be read from preferences and applied at runtime.

I can declare a listview. What are the columns? Those are probably read from preferences. Along with their order and sorting preference. So I can't declare that in QML, I need to dynamically create the GUI in window creation code.

GUI style: basic/advanced. I might be able to get away with different QML files for that, although I need to figure out which QML file to use in runtime (because I need to read it from prefs), so I can't hardcode it.

Maybe the main window can have a splitter in the middle. In this case the left and right widget needs to be saved/restored somehow, and the splitter position needs to be persisted. Maybe we support tabs in the main window, and those tabs could be dragged outside of our window into a separate standalone window. We need to serialize the state of the window manager, and deserialize it later, so user preference would be preserved. Is the scrollbar standard or custom? Because we might be doing a text editor and we maybe want to support visualizing buffer map inside the scrollbar. This widget is probably fully owner-drawn anyway, so can't be declared in the QML.

I guess nowadays most of those topics are not even considered because there is no such thing as user preference for GUI. User takes what the javascript developer gives, nothing more, nothing less.

Re: Qt 6.6 and 6.7 Make QML Faster Than Ever: A New Benchmark and Analysis

#23

Post by st_goliath »

I'm a C programmer with occasional stints in C++, a language that I admittedly have a complicate relation ship with. Personally, I was quite pleased with Qt 5 & Qml when I got to work with it some time back.

I commented on my opinion on Qt/Qml once before: https://news.ycombinator.com/item?id=35652347

I'm mentioning this here because, as already noted in my previous post, HN threads on Qt have this bizarre tendency to attract some really weird FUD/shit-flinging.

Qt is nothing like Electron. It is nowhere near that, or "underperfoming" in comparsion. In my previous post, I even specifically mentioned how the projection I was on was replacing a Chromium + REST backed based stack on an embedded device with Qt, because that was a slow resource hog in comparison. Somehow I have my doubts that comments like that come from actual experience.

Re: Qt 6.6 and 6.7 Make QML Faster Than Ever: A New Benchmark and Analysis

#24

Post by klabb3 »

wiz21c wrote: post #19
soundarana wrote: post #11

> Another thing you can immediately see is that the QML version of the algorithm is generally much slower than the JavaScript version. As noted above, this is due to it being built on QObjects rather than JavaScript objects. Of course, QML is trying to beat the browser at it's own game, but can't match the billions invested in browser performance. Qt classic is dead, and QML is a less featured, less documented, under…

not excatly on topic but is something is Tauri better than Electron (in terms of memory usage and disk footprint) ?

Short answer: yes. Tauri is using your OS own web view instead of shipping y’know… entire Chrome. And for native stuff, it’s generally faster and smaller with Rust than… checks notes… the entire Node runtime.

In short, it’s not super hard to beat electron especially in terms of disk/memory.

Now, that said. Many of you think you suffer because web=slow, JavaScript=bad yadda yadda. But this is often not true at all, which almost always turns up in apples-to-apples benchmarks. In fact, the suffering is almost always because of lazy/hypey/bloated stacks full of ads/multiple cloud backends for metrics, ads, logging, etc etc/poor coding standars etc etc. So the long answer is that Tauri won’t help with those deeper issues.

Re: Qt 6.6 and 6.7 Make QML Faster Than Ever: A New Benchmark and Analysis

#25

Post by eviks »

self_awareness wrote: post #22
notyoutube wrote: post #9

Earlier quoted context omitted.

I've got a potential example; I always wondered how that would be achieved with something like slint or qml: With tools like xournal++ or other things like document processors, you can usually define your own panels, reorganize them, move them around, add icons or separators, etc, and all of that in a drag&drop fashion, live from the program running. I feel like having a (compile-time) declarative description of that…

Yes, panels are one example. Which panel goes to which window corner? What is the resize policy? It will probably be read from the file according to user preference, so it can't be hardcoded declaratively in QML. What is the current theme? Window position? Maximized/minimized state? Those need to be read from preferences and applied at runtime. I can declare a listview. What are the columns? Those are probably read f…

> nowadays most of those topics are not even considered because there is no such thing as user preference for GUI.

very sad state of affairs indeed

Re: Qt 6.6 and 6.7 Make QML Faster Than Ever: A New Benchmark and Analysis

#26

Post by nine_k »

lmm wrote: post #21
sourcegrift wrote: post #2

As a Rust user, very happy with qmetaobject-rs. It was really a breeze to make a basic GUI for personal use ... I would also add an opinion: Qt is a great fit for Rust. GUI toolkits (=presentation layer) is best done declaratively and QML does an amazing job at it. Keep in mind that making a GUI kit, specially for 5 platforms in a way that it runs and feels uniformly across them all is a herculean task that returns n…

> even if I can write some GUI in a "rusty" way, it won't suddenly speed up things because GUI is almost never a bottleneck. Nor are any of the other things people use Rust for, but that doesn't seem to reduce the enthusiasm any.

Rust does not make your rocket fly faster, but it lowers the chance that it would explode mid-flight.

Re: Qt 6.6 and 6.7 Make QML Faster Than Ever: A New Benchmark and Analysis

#27

Post by _8j50 »

I just wanna say I've been a fan of Qt and its contribution to native UI, KDE is awesome and all. I just wish there were good qml supporting easy to use libraries in modern languages that wrapped it because I can't do C++ unless someome is paying me good money and full time for it. Not fun for side projects.

Re: Qt 6.6 and 6.7 Make QML Faster Than Ever: A New Benchmark and Analysis

#28

Post by amelius »

actionfromafar wrote: post #4
sourcegrift wrote: post #2

As a Rust user, very happy with qmetaobject-rs. It was really a breeze to make a basic GUI for personal use ... I would also add an opinion: Qt is a great fit for Rust. GUI toolkits (=presentation layer) is best done declaratively and QML does an amazing job at it. Keep in mind that making a GUI kit, specially for 5 platforms in a way that it runs and feels uniformly across them all is a herculean task that returns n…

Do you mean it’s no point in writing a GUI toolkit in Rust?

It would make sense to have a library that can do basic Svg/Canvas things, in Rust. From there, people can write all sorts of GUI libraries.

Re: Qt 6.6 and 6.7 Make QML Faster Than Ever: A New Benchmark and Analysis

#29

Post by sircastor »

In my last role we were using QML as a prototyping tool for interfaces, and basically making whole proof-of-concept apps in it. It is immensely powerful once you get the hang of it. Though if anyone is thinking about it, please note that it is not (or wasn't) really a language on its own. It's meant as a UI complement for Qt, and trying to build stuff exclusively in QML is a recipe for tears.

Re: Qt 6.6 and 6.7 Make QML Faster Than Ever: A New Benchmark and Analysis

#30

Post by eql5 »

_8j50 wrote: post #27

I just wanna say I've been a fan of Qt and its contribution to native UI, KDE is awesome and all. I just wish there were good qml supporting easy to use libraries in modern languages that wrapped it because I can't do C++ unless someome is paying me good money and full time for it. Not fun for side projects.

If you like Common Lisp, here is one:

https://gitlab.com/eql/lqml

Post reply on HN