Re: [Interest] QEvent::Quit vs. QEvent::Close
> On 23 Oct 2023, at 22:30, Hamish Moffatt via Interest > wrote: > > On 24/10/23 06:10, Alexander Dyagilev wrote: >> I would prefer for an additional event to be used when the user triggers >> Quit. E.g. something like QEvent::QuitByUser. >> >> For now, it seems I will have to involve some additional ugly logics >> (something like setting a global variable) More code more complexity for >> such a simple situation. Not good, IMO. > > > Does QEvent::spontaneous() tell you anything about the two different quit > events? > > Hamish They should; the window system event is handled as a spontaneous event and should reach Q(Gui)Application::event with the spontaneous flag set; a call to Q(Core)Application::quit sends (or posts, depending on the thread) the event as a synthetic event to the qApp instance, so the spontaneous flag will not be set. Volker ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] QEvent::Quit vs. QEvent::Close
On 24/10/23 06:10, Alexander Dyagilev wrote: I would prefer for an additional event to be used when the user triggers Quit. E.g. something like QEvent::QuitByUser. For now, it seems I will have to involve some additional ugly logics (something like setting a global variable) More code more complexity for such a simple situation. Not good, IMO. Does QEvent::spontaneous() tell you anything about the two different quit events? Hamish ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] How to avoid qml engine repeatedly copying and garbage collecting qstringlists?
Actually, funnily enough, Qt.fontfamilies is an order of magnitude faster
than custom property wrapping the result of ::families. Dunno why. 5s vs
500 ms for the sue case
Still, checking on .lncludes(name) in javascript is seemingly also an order
of magnitude slower than sending family name to c++ and prematurely exiting
from there. 500 ms vs <50ms
On Mon, Oct 23, 2023 at 8:58 PM Ulf Hermann wrote:
> > doesn't QtQuickGuiProvider do the exact same thing with
> QfontDatabase::families?
>
> Yes, it does. It returns a QStringList. What I mean is that you don't
> need a custom C++ base class for your singleton if all you want to do is
> expose the font families in pre-wrapped form. The following is enough
> for that:
>
> pragma Singleton
> import QtQml
>
> QtObject {
> // Qt5:
> property var wrappedFontFamilies5: Qt.fontFamilies()
>
> // Qt6:
> property list wrappedFontFamilies6: Qt.fontFamilies()
> }
>
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
[Interest] Problems with qt_add_qml_module
Hello, I'm trying to create a QML extension module using CMake, and I've run into some road blocks. I want to create a QML module including a "plugin", based on my own code rather than an auto-generated plugin stub. I assume I'll have to define my own plugin target and then use `target_include_directories()`, `target_link_libraries()` etc. to specify how to compile and link it. What are the appropriate options to be used with `qt_add_qml_module()` to make that module target aware of my plugin ? I tried to follow the documentation and use https://doc.qt.io/qt-6.5/qt-add-qml-module.html#no-create-plugin-target, but this results in an error as `target_link_libraries()` is used multiple times for the same target, i.e. apparently `qt_add_qml_module()` is calling it itself, despite my using `NO_CREATE_PLUGIN_TARGET`. Am I missing something, or is this a bug ? Are there any examples that demonstrate how to use `qt_add_qml_module()` with a custom (non-trivial) plugin ? Thanks. -- ...ich hab' noch einen Koffer in Berlin... ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] QEvent::Quit vs. QEvent::Close
I would prefer for an additional event to be used when the user triggers Quit. E.g. something like QEvent::QuitByUser. For now, it seems I will have to involve some additional ugly logics (something like setting a global variable) More code more complexity for such a simple situation. Not good, IMO. On 10/23/2023 10:05 PM, Alexander Dyagilev wrote: Hello, In Qt 5.x we had QEvent::Close when the user was using Dock to quit our application. Now, this is not the case and QEvent::Quit is used instead. However, the same QEvent::Quit is used when my code calls qApp->quit somewhere. Is it possible to distinguish these two situations? ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
[Interest] QEvent::Quit vs. QEvent::Close
Hello, In Qt 5.x we had QEvent::Close when the user was using Dock to quit our application. Now, this is not the case and QEvent::Quit is used instead. However, the same QEvent::Quit is used when my code calls qApp->quit somewhere. Is it possible to distinguish these two situations? ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] How to avoid qml engine repeatedly copying and garbage collecting qstringlists?
doesn't QtQuickGuiProvider do the exact same thing with QfontDatabase::families?
Yes, it does. It returns a QStringList. What I mean is that you don't
need a custom C++ base class for your singleton if all you want to do is
expose the font families in pre-wrapped form. The following is enough
for that:
pragma Singleton
import QtQml
QtObject {
// Qt5:
property var wrappedFontFamilies5: Qt.fontFamilies()
// Qt6:
property list wrappedFontFamilies6: Qt.fontFamilies()
}
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
Re: [Interest] How to avoid qml engine repeatedly copying and garbage collecting qstringlists?
Ahem... I tried searching with https://codebrowser.dev/ and doesn't
QtQuickGuiProvider do the exact same thing with QfontDatabase::families?
Unless I misunderstand something it should hit exactly the same problem
with copying the stringlist and then Qt.fontFamilies isn't the solution?
On Mon, Oct 23, 2023 at 6:38 PM Ulf Hermann wrote:
> > The question though is whether this would be a singleton per qmlengine.
> > If it will, then that's a nogo as the list of loaded fonts needs to
> > exist once regardless of how much engines are running
>
> Singletons are created once per engine, even C++ ones. You should not
> subvert this. And you cannot safely share JavaScript objects across
> engines anyway.
>
> What you _can_ do is have your SingletonBase redirect the property
> access to some other place that holds a unique list of font families.
> You can write the getter for a Q_PROPERTY any way you like after all. If
> you have a QList for the font families, redirecting through one
> more function call is not a big performance hit, due to implicit
> sharing. And since your actual access to the font families is via the
> QML-defined property, each engine will access the original font families
> only once. So:
>
> // singletonbase.h
> class SingletonBase : public QObject
> {
> Q_OBJECT
> QML_ELEMENT
> // Not a singleton!
> Q_PROPERTY(QStringList internalFontFamilies READ
> internalFontFamilies CONSTANT FINAL)
> public:
> QStringList internalFontFamilies() {
> // The enclosing object does not have to be a singleton
> // in order to return singular data from some getter!
> return QFontDatabase::families()
> }
> };
>
> I feel we're touching on a common misconception that many people
> struggle with. Just because some data is conceptually static, you don't
> need to nail it down to a single static QObject. You can just return the
> static data from some method. Each QML engine you expose a single static
> QObject to will try to create its own QObject wrapper. Since we can only
> store one QObject wrapper in the pointer exposed by QObjectPrivate, this
> leads to a hilarious amount of complexity on the side of the QML
> engines. It is also a giant foot gun waiting to trigger when you create
> more than one thread. Yes, it is possible to manage all of this, but
> just don't do it. Let each engine each have its own singleton object and
> dispatch the data in the C++ code you have to write anyway.
>
> By the way, there is also Qt.fontFamilies(). If that is all you need,
> you don't need a special C++ backing type for your singleton at all.
>
> best regards,
> Ulf
>
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
Re: [Interest] How to avoid qml engine repeatedly copying and garbage collecting qstringlists?
The question though is whether this would be a singleton per qmlengine.
If it will, then that's a nogo as the list of loaded fonts needs to
exist once regardless of how much engines are running
Singletons are created once per engine, even C++ ones. You should not
subvert this. And you cannot safely share JavaScript objects across
engines anyway.
What you _can_ do is have your SingletonBase redirect the property
access to some other place that holds a unique list of font families.
You can write the getter for a Q_PROPERTY any way you like after all. If
you have a QList for the font families, redirecting through one
more function call is not a big performance hit, due to implicit
sharing. And since your actual access to the font families is via the
QML-defined property, each engine will access the original font families
only once. So:
// singletonbase.h
class SingletonBase : public QObject
{
Q_OBJECT
QML_ELEMENT
// Not a singleton!
Q_PROPERTY(QStringList internalFontFamilies READ
internalFontFamilies CONSTANT FINAL)
public:
QStringList internalFontFamilies() {
// The enclosing object does not have to be a singleton
// in order to return singular data from some getter!
return QFontDatabase::families()
}
};
I feel we're touching on a common misconception that many people
struggle with. Just because some data is conceptually static, you don't
need to nail it down to a single static QObject. You can just return the
static data from some method. Each QML engine you expose a single static
QObject to will try to create its own QObject wrapper. Since we can only
store one QObject wrapper in the pointer exposed by QObjectPrivate, this
leads to a hilarious amount of complexity on the side of the QML
engines. It is also a giant foot gun waiting to trigger when you create
more than one thread. Yes, it is possible to manage all of this, but
just don't do it. Let each engine each have its own singleton object and
dispatch the data in the C++ code you have to write anyway.
By the way, there is also Qt.fontFamilies(). If that is all you need,
you don't need a special C++ backing type for your singleton at all.
best regards,
Ulf
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
Re: [Interest] How to avoid qml engine repeatedly copying and garbage collecting qstringlists?
Oh, I see, yeah, that makes sense. Just singleton a wrapper,
The question though is whether this would be a singleton per qmlengine. If
it will, then that's a nogo as the list of loaded fonts needs to exist once
regardless of how much engines are running
On Mon, Oct 23, 2023 at 5:51 PM Ulf Hermann wrote:
> > How is instantiating a new c++ instance each time faster than
> > referencing a c++ side singleton??
>
> This is not what I meant. I mean:
>
> // singletonbase.h
> class SingletonBase : public QObject
> {
> Q_OBJECT
> QML_ELEMENT
> // Not a singleton!
> Q_PROPERTY( ... )
> public:
> Q_INVOKABLE ...
> };
>
> // Singleton.qml
> pragma Singleton
> import TheModuleThatHasSingletonBase
>
> SingletonBase {
> property var fontFamilies: find.the.font.families
> ...
> }
>
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
Re: [Interest] How to avoid qml engine repeatedly copying and garbage collecting qstringlists?
How is instantiating a new c++ instance each time faster than
referencing a c++ side singleton??
This is not what I meant. I mean:
// singletonbase.h
class SingletonBase : public QObject
{
Q_OBJECT
QML_ELEMENT
// Not a singleton!
Q_PROPERTY( ... )
public:
Q_INVOKABLE ...
};
// Singleton.qml
pragma Singleton
import TheModuleThatHasSingletonBase
SingletonBase {
property var fontFamilies: find.the.font.families
...
}
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
Re: [Interest] How to avoid qml engine repeatedly copying and garbage collecting qstringlists?
> instantiate a non-singleton type declared in C++ rather than referencing yet another singleton How is instantiating a new c++ instance each time faster than referencing a c++ side singleton?? On Mon, Oct 23, 2023 at 5:44 PM Ulf Hermann wrote: > > So do I use `pragma Singleton` to wrap a c++ singleton into a qml one > > declaring such a var property? > > That would be one way to do it. I don't know what your singleton looks > like. Maybe it can be defined in QML and instantiate a non-singleton > type declared in C++ rather than referencing yet another singleton. That > would probably be faster. > > best regards, > Ulf > ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] How to avoid qml engine repeatedly copying and garbage collecting qstringlists?
So do I use `pragma Singleton` to wrap a c++ singleton into a qml one declaring such a var property? That would be one way to do it. I don't know what your singleton looks like. Maybe it can be defined in QML and instantiate a non-singleton type declared in C++ rather than referencing yet another singleton. That would probably be faster. best regards, Ulf ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] How to avoid qml engine repeatedly copying and garbage collecting qstringlists?
On 10/23/23 16:37, NIkolai Marchenko wrote: > If you cannot port to Qt6 and compile the QML code to C++ Unfortunately qt6 broke too much of Qt Quick 1 that porting will require non trivial effort. Are you really still using QtQuick 1? It had been unsupported for years already before Qt6 happened. best regards, Ulf ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] How to avoid qml engine repeatedly copying and garbage collecting qstringlists?
> If you store the value of the property in a var So do I use `pragma Singleton` to wrap a c++ singleton into a qml one declaring such a var property? On Mon, Oct 23, 2023 at 5:37 PM NIkolai Marchenko wrote: > > If you cannot port to Qt6 and compile the QML code to C++ > > Unfortunately qt6 broke too much of Qt Quick 1 that porting will require > non trivial effort. > > On Mon, Oct 23, 2023 at 5:35 PM Ulf Hermann wrote: > >> > So, should I send the value from qml to c++ to do a search there >> > instead? It's the solution I ended up doing but I hoped storing >> > something on JS side was possible to not cross language boundaries on >> > each item initialization. >> >> If you cannot port to Qt6 and compile the QML code to C++, this may be >> one of the rare cases where you might use a var property in QML. If you >> store the value of the property in a var, the list wrapper is stored, >> not only the list value. Whenever you access it from elsewhere, the >> engine will use the same list wrapper again. >> >> In Qt6 you can use a list instead of var for the same effect, >> but with type. >> >> (At least this is how it should work. I don't think we have a test for >> this particular case. So, if it doesn't work, please file a bug) >> >> best regards, >> Ulf >> > ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] How to avoid qml engine repeatedly copying and garbage collecting qstringlists?
> If you cannot port to Qt6 and compile the QML code to C++ Unfortunately qt6 broke too much of Qt Quick 1 that porting will require non trivial effort. On Mon, Oct 23, 2023 at 5:35 PM Ulf Hermann wrote: > > So, should I send the value from qml to c++ to do a search there > > instead? It's the solution I ended up doing but I hoped storing > > something on JS side was possible to not cross language boundaries on > > each item initialization. > > If you cannot port to Qt6 and compile the QML code to C++, this may be > one of the rare cases where you might use a var property in QML. If you > store the value of the property in a var, the list wrapper is stored, > not only the list value. Whenever you access it from elsewhere, the > engine will use the same list wrapper again. > > In Qt6 you can use a list instead of var for the same effect, > but with type. > > (At least this is how it should work. I don't think we have a test for > this particular case. So, if it doesn't work, please file a bug) > > best regards, > Ulf > ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] How to avoid qml engine repeatedly copying and garbage collecting qstringlists?
So, should I send the value from qml to c++ to do a search there instead? It's the solution I ended up doing but I hoped storing something on JS side was possible to not cross language boundaries on each item initialization. If you cannot port to Qt6 and compile the QML code to C++, this may be one of the rare cases where you might use a var property in QML. If you store the value of the property in a var, the list wrapper is stored, not only the list value. Whenever you access it from elsewhere, the engine will use the same list wrapper again. In Qt6 you can use a list instead of var for the same effect, but with type. (At least this is how it should work. I don't think we have a test for this particular case. So, if it doesn't work, please file a bug) best regards, Ulf ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] How to avoid qml engine repeatedly copying and garbage collecting qstringlists?
> it would be interesting to see the QML code that produces this behavior.
I was optimizing stack memory reservation used for ensuring that fonts are
loaded inside the custom TextLabel items after my previous question you
answered (about javascript stack reservation and Loaders) and made a
singleton to pass the requests to load font to c++ side as opposed to
keeping a Loader and FontLocator inside every text element. As a result I
ended up needing to query whether the font has already been loaded yet and
tried to pass a families() result to qml with the results from the original
post so that I don't have to enter loading func on the.c++ time every time.
So in essense:
TextLabel{ // a subclass of Text
on__FontFamilyChanged: {
if(FontLoaderSingleton.loadedFonts.includes(font.family)) // BOOM!
Everything slows to a crawl
}
}
Note that this hits yet another bug that has been fixed in qt6 I had to
work around, as in qt not resetting cache glyphs for font that hasn't been
loaded when original query was made... >_<
On Mon, Oct 23, 2023 at 4:57 PM NIkolai Marchenko
wrote:
> > Sounds to me, you are looking for a QStringListModel.
>
> I am not sure how qstringlistmodel will help matters tbh
>
> > There is no simple solution for this.
>
> So, should I send the value from qml to c++ to do a search there instead?
> It's the solution I ended up doing but I hoped storing something on JS side
> was possible to not cross language boundaries on each item initialization.
>
>
> On Mon, Oct 23, 2023 at 4:35 PM Ulf Hermann via Interest <
> interest@qt-project.org> wrote:
>
>> Hi Nikolai,
>>
>> it would be interesting to see the QML code that produces this behavior.
>> However, I can very well imagine what's happening there. This is likely
>> the "value type reference" problem. The list is a "sequence type". It
>> doesn't have an identity of its own but rather is only accessible as a
>> copy from your property. However, in JavaScript there is no such thing
>> as a value (or sequence) type. There are only objects and each object
>> has a unique identity. Therefore, your list, upon access from
>> JavaScript, is wrapped into a special JavaScript object so that you can
>> interact with it. The special object gives you the illusion of a
>> separate entity by refreshing its copy of the list whenever you read
>> from it and by writing the copy back to the property whenever you change
>> it. The illusion breaks down when you retrieve the list a second time,
>> though. Lacking any actual identity information, the QML engine cannot
>> find other instances of the same list when accessing it again. Therefore
>> it has to create a new wrapper object every time.
>>
>> In contrast to that, for QObject-derived types we have actual identity
>> information. QObjectPrivate has a field for "declarative data" and there
>> we store a pointer to the JavaScript wrapper.
>>
>> There is no simple solution for this. We could probably add some
>> book-keeping to our QObject wrapper in order to figure out which
>> properties already have sequence (and value type) wrappers. This is more
>> complicated than it sounds because value types can have properties of
>> their own, value types can be stored in lists, and all of this
>> recursively.
>>
>> If you get qmlcachegen to compile the code to C++ with Qt6, you won't
>> see the JavaScript wrappers for lists and value types anymore. The
>> generated C++ code can store the values on the C++ stack instead. But
>> there are restrictions: In the generated C++ code we can _not_ honor the
>> object-like nature of value type and sequence references. Anything that
>> would exploit it won't be compiled to C++. In particular, any function
>> call and any writing to a property invalidates all value type and
>> sequence instances currently on the stack. This is because their source
>> properties may have been changed by code triggered from the function
>> call or property write.
>>
>> best regards,
>> Ulf
>> ___
>> Interest mailing list
>> Interest@qt-project.org
>> https://lists.qt-project.org/listinfo/interest
>>
>
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
Re: [Interest] Strategies to debug and improve UI performance (QML)
I was just recently doing exactly this, here's what I did: 1) Watch this excellent presentation by Guiseppe D'Angelo: https://www.youtube.com/watch?v=3g4mOq9doIo 2) Download gammaray from KDAB, this will let you see what is what on your scene and which signals are being (overenthusiastically) emitted and which objects exist in which quanitties 3) Do NOT use qt creator for profiling c++ side, instead use perf + hotspot combination to see where the app is stalling the most 4) DO use qml profiler in qt creator for profiling qml side, it will show you which functions in qml are taking valuable time 5) There's some really fishy behaviour with clipping that might trip up your batching, in our case a custom line edit with a clipping behaviour ensured every Text entity is a separate draw call. 6) Make sure your application isn't stalling on qwaitconditions due to overenthusiastic asynchronicity P.S. These are the reference materials I used while figuring stuff out myself: https://doc.qt.io/qt-5/qtquick-visualcanvas-scenegraph-renderer.html http://imaginativethinking.ca/qt-quick-performance-tips-rectangles/ https://doc.qt.io/qt-5/qtquick-performance.html https://doc.qt.io/qt-5/qml-qtqml-workerscript-workerscript.html#details http://mirror.thecust.net/meego_1.2_harmattan_developer_documentation/html/guide/html/Developer_Library_Best_practices_for_application_development_QML_performance_tips_and_tricks.html https://doc.qt.io/qt-6/qtquick-bestpractices.html https://doc.qt.io/qt-5/best-practices.html On Mon, Oct 23, 2023 at 4:22 PM Nuno Santos wrote: > Hi, > > I want to perform a UI optimisation. I would like to know how many items > are being instantiated, and who is taking more time to load, etc > > Are there ENV variables and tools that could help in this task? > > I would love to hear your thoughts. > > Best regards, > > Nuno > ___ > Interest mailing list > Interest@qt-project.org > https://lists.qt-project.org/listinfo/interest > ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] How to avoid qml engine repeatedly copying and garbage collecting qstringlists?
> Sounds to me, you are looking for a QStringListModel. I am not sure how qstringlistmodel will help matters tbh > There is no simple solution for this. So, should I send the value from qml to c++ to do a search there instead? It's the solution I ended up doing but I hoped storing something on JS side was possible to not cross language boundaries on each item initialization. On Mon, Oct 23, 2023 at 4:35 PM Ulf Hermann via Interest < interest@qt-project.org> wrote: > Hi Nikolai, > > it would be interesting to see the QML code that produces this behavior. > However, I can very well imagine what's happening there. This is likely > the "value type reference" problem. The list is a "sequence type". It > doesn't have an identity of its own but rather is only accessible as a > copy from your property. However, in JavaScript there is no such thing > as a value (or sequence) type. There are only objects and each object > has a unique identity. Therefore, your list, upon access from > JavaScript, is wrapped into a special JavaScript object so that you can > interact with it. The special object gives you the illusion of a > separate entity by refreshing its copy of the list whenever you read > from it and by writing the copy back to the property whenever you change > it. The illusion breaks down when you retrieve the list a second time, > though. Lacking any actual identity information, the QML engine cannot > find other instances of the same list when accessing it again. Therefore > it has to create a new wrapper object every time. > > In contrast to that, for QObject-derived types we have actual identity > information. QObjectPrivate has a field for "declarative data" and there > we store a pointer to the JavaScript wrapper. > > There is no simple solution for this. We could probably add some > book-keeping to our QObject wrapper in order to figure out which > properties already have sequence (and value type) wrappers. This is more > complicated than it sounds because value types can have properties of > their own, value types can be stored in lists, and all of this recursively. > > If you get qmlcachegen to compile the code to C++ with Qt6, you won't > see the JavaScript wrappers for lists and value types anymore. The > generated C++ code can store the values on the C++ stack instead. But > there are restrictions: In the generated C++ code we can _not_ honor the > object-like nature of value type and sequence references. Anything that > would exploit it won't be compiled to C++. In particular, any function > call and any writing to a property invalidates all value type and > sequence instances currently on the stack. This is because their source > properties may have been changed by code triggered from the function > call or property write. > > best regards, > Ulf > ___ > Interest mailing list > Interest@qt-project.org > https://lists.qt-project.org/listinfo/interest > ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] How to avoid qml engine repeatedly copying and garbage collecting qstringlists?
Hi Nikolai, it would be interesting to see the QML code that produces this behavior. However, I can very well imagine what's happening there. This is likely the "value type reference" problem. The list is a "sequence type". It doesn't have an identity of its own but rather is only accessible as a copy from your property. However, in JavaScript there is no such thing as a value (or sequence) type. There are only objects and each object has a unique identity. Therefore, your list, upon access from JavaScript, is wrapped into a special JavaScript object so that you can interact with it. The special object gives you the illusion of a separate entity by refreshing its copy of the list whenever you read from it and by writing the copy back to the property whenever you change it. The illusion breaks down when you retrieve the list a second time, though. Lacking any actual identity information, the QML engine cannot find other instances of the same list when accessing it again. Therefore it has to create a new wrapper object every time. In contrast to that, for QObject-derived types we have actual identity information. QObjectPrivate has a field for "declarative data" and there we store a pointer to the JavaScript wrapper. There is no simple solution for this. We could probably add some book-keeping to our QObject wrapper in order to figure out which properties already have sequence (and value type) wrappers. This is more complicated than it sounds because value types can have properties of their own, value types can be stored in lists, and all of this recursively. If you get qmlcachegen to compile the code to C++ with Qt6, you won't see the JavaScript wrappers for lists and value types anymore. The generated C++ code can store the values on the C++ stack instead. But there are restrictions: In the generated C++ code we can _not_ honor the object-like nature of value type and sequence references. Anything that would exploit it won't be compiled to C++. In particular, any function call and any writing to a property invalidates all value type and sequence instances currently on the stack. This is because their source properties may have been changed by code triggered from the function call or property write. best regards, Ulf ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
[Interest] Strategies to debug and improve UI performance (QML)
Hi, I want to perform a UI optimisation. I would like to know how many items are being instantiated, and who is taking more time to load, etc Are there ENV variables and tools that could help in this task? I would love to hear your thoughts. Best regards, Nuno ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] How to avoid qml engine repeatedly copying and garbage collecting qstringlists?
On 10/23/23 11:41, NIkolai Marchenko wrote: Qt 5.15.2 I've encountered a strange behaviour while trying to pass the output of QFontDatabase::families() into qml via Q_PROPERTY of a singleton class. Essentially - I have a ton of qml items accessing this property in their initialization and every one of them is doing an .includes search on it. What happened is it has produced an absolutely massive slowdown and after perfing what's happening there it seems like qml engine is repeatedly recreating this stringlist inside the engine and garbage collecting it on every access instead of keeping it around. Is there something that can be done about it and what is even happening there? Sounds to me, you are looking for a QStringListModel. Cheers, Frank ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
[Interest] How to avoid qml engine repeatedly copying and garbage collecting qstringlists?
Qt 5.15.2 I've encountered a strange behaviour while trying to pass the output of QFontDatabase::families() into qml via Q_PROPERTY of a singleton class. Essentially - I have a ton of qml items accessing this property in their initialization and every one of them is doing an .includes search on it. What happened is it has produced an absolutely massive slowdown and after perfing what's happening there it seems like qml engine is repeatedly recreating this stringlist inside the engine and garbage collecting it on every access instead of keeping it around. Is there something that can be done about it and what is even happening there? ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
