[Interest] How to avoid qml engine repeatedly copying and garbage collecting qstringlists?

[NIkolai Marchenko]

>  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 <enmarantispam at gmail.com>
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 at 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 at qt-project.org
>> https://lists.qt-project.org/listinfo/interest
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20231023/48529bd6/attachment.htm>