News for hackers. Stuff that matters.
Re:Using Qt for Mobile in 2023 by rubymamis on Tuesday December 26, 2023 @12:18AM (#38769119)
Thanks for sharing! What performance issue are you talking about? Did you separate your logic to C++? I'm building an advanced block editor[1] where the model is in C++ and the view in QML and the performance is really great.

The scrolling like you mentioned is subpar compared to native macOS one, so I hope Qt will address that. I saw someone mentioning `flickDeceleration` but at least on desktop it doesn't seem to change anything? Maybe it's because my delegates are so different from each other?

I also plan to support mobile version for my app in the future, so it's sad to read about the rest of the issues.

[1] https://www.get-plume.com/

Re:Using Qt for Mobile in 2023 by _camm on Tuesday December 26, 2023 @02:21AM (#38769565)
I haven't seen any performance issues on desktop, but on mobile they really stand out. I have separated logic into QML, and even experimented with implementing custom QQuickItems in some places.

Here are some issues I've seen related to performance on mobile:

1) Opening a larger app is really slow (maybe 3-5 seconds), but works okay for smaller apps. I'm not sure what's going on behind the scenes and haven't had time to dive deep there yet, so this could be specific to me.

2) Rendering full pages is quite slower than native, as is QML rendering in general, even when using the QML compiler (which compiles your QML to C++)

3) Qt text rendering is a bit slow too, but you may not need i.e QTextDocument if you're implementing a text editor of some sort.

Re:Using Qt for Mobile in 2023 by rubymamis on Tuesday December 26, 2023 @03:09AM (#38769778)
These performance issues are vastly different from what I experience on Desktop, so I'm curious to test my app on mobile. In my experience, C++ and QML outperforms comparable native apps by 4x.

Regarding no.3, what do you mean by QTextDocument? My block editor is implemented by each delegate being a TextArea (inh: TextEdit), and it's very fast.

One trick I've learned, is to use `reuseItems`[1][2] in ListView. It gives incredible performance boost. You'll need to adjust some things according to the onPooled and onReused signals, but it's a no-brainer for many use cases.

[1] https://doc.qt.io/qt-6/qml-qtquick-listview.html#reuseItems-...

[2] https://doc.qt.io/qt-6/qml-qtquick-tableview.html#reusing-it...

Re:Using Qt for Mobile in 2023 by _camm on Tuesday December 26, 2023 @03:48AM (#38770003)
QTextDocument is a class in Qt::Gui that many of the other text classes/components use. I was thinking you may have implemented your own text handling widget/item, but using delegates of text areas makes sense too.

I will try reuseItems again. It's something I tried before briefly but thought it may have been causing some rendering glitches and removed it. Maybe because I didn't implement onResused or onPooled properly. Thanks!

Re:Using Qt for Mobile in 2023 by rubymamis on Tuesday December 26, 2023 @04:02AM (#38770079)
> I was thinking you may have implemented your own text handling

Yes, but without QTextDocument as I had some problems with it. I had to implement my own undo/redo/copy/paste/etc.

> It's something I tried before briefly but thought it may have been causing some rendering glitches

Yes, I've experienced some (minor) glitches that I've yet to figure out how to fix. For example, the cursor seems to (sometimes) jump when creating new blocks. Sometimes delegates reappear with animation (while I turned them off when onPooled ran). I'm trying to figure out if I'm doing something incorrectly (highly probable) yet I don't get these issues without reuseItems.

Sure, I hope it works out well for you (:

Re:Using Qt for Mobile in 2023 by ahartmetz on Tuesday December 26, 2023 @03:04AM (#38769752)
Regarding your first point, instantiating a lot of QML items is usually what makes startup slow. You can use Loaders to load things on demand (and timer triggered Loaders to load stuff you will probably need but shouldn't delay startup). Make the Loaders asynchronous and timer triggered (async but immediately triggered still slows down startup) and switch them to synchronous when their contents are needed immediately.

I have a component for it, it's 10-15 lines or so.

Re:Using Qt for Mobile in 2023 by coffeeaddict1 on Tuesday December 26, 2023 @07:19AM (#38771156)
Hmm, for 1 and 2 have you actually tried to profile your code? You can use the QML profiler to check which parts of QML compilation are slowing you down. Also consider using GammaRay [1] to see what's causing the rendering to be slow.

[1] https://www.kdab.com/development-resources/qt-tools/gammaray...

Re:Using Qt for Mobile in 2023 by _camm on Tuesday December 26, 2023 @01:25PM (#38774385)
I'll try GammaRay. Thank you for the recommendation. I've tried the QML profiler before but I always have difficulty getting it to work on Android.
Re:Using Qt for Mobile in 2023 by zerr on Tuesday December 26, 2023 @03:35AM (#38769922)
For something more data demanding, e.g. a video player, do you have to copy every frame from C++ world to QML/JavaScript in order to display it?
Re:Using Qt for Mobile in 2023 by LtWorf on Tuesday December 26, 2023 @04:13AM (#38770130)
No, you'd use something like libmpv and tell it to which rectangle render the video.
Re:Using Qt for Mobile in 2023 by _camm on Tuesday December 26, 2023 @03:53AM (#38770033)
It's possible to implement custom QQuickItems that you render in C++, and are displayed within your QML somewhere.

https://doc.qt.io/qt-6/qquickitem.html

Re:Using Qt for Mobile in 2023 by rubymamis on Tuesday December 26, 2023 @03:38AM (#38769945)
I never dealt with video, so I don't know, but I assume there are Qt Quick components for this?[1]

[1] https://doc.qt.io/qt-6/qtmultimedia-video-mediaplayer-exampl...

Re:Using Qt for Mobile in 2023 by saidinesh5 on Tuesday December 26, 2023 @06:50AM (#38770974)
This really depends on the target platform , Qt version you are using. To put things into perspective, With Gstreamer/QML, we've had smooth 1080p30 fps on measly imx6ul hardware, thanks to zero copy pipelines.