Details
-
Bug
-
Resolution: Unresolved
-
P2: Important
-
None
-
5.12.8, 5.14.2
Description
In certain circumstances, it seems that the QSGBatchRenderer will hold on to nodes that have been removed far longer than necessary. This can cause an issue, if nodes are being created and removed frequently in a long-lived application (e.g., every second on a clock left running overnight).
I have attempted to isolate the exact conditions that cause this, but so far have been unsuccessful. If I'm able to isolate it, I will update this description with a minimal reproducible example. In the meantime, here are the details as best I've been able to find.
In our QML application, we have a QML structure essentially similar to the following:
Window {
property string text
Loader {
sourceComponent: {
Repeater {
model: text.split("")
Text {
text: modelData
{{ }}}
{{ }}}
Item {}
Item {}
// etc...
{{ }}}
{{ }}}
Timer {
interval: 1
repeat: true
onTriggered: text = Math.random().toFixed(10)
{{ }}}
}
(Note that this simple example does not reproduce the situation. I am still trying to find the precise conditions which cause it.) Neither the repeater, nor the repeated components are referenced elsewhere, and there should be nothing keeping them alive when the Repeater model property changes.
After leaving the application running overnight, we attempt to change the Loader's component. This causes an application hang as the Renderer deletes millions of elements from its m_elementsToDelete list.
Stack trace:
Renderer::deleteRemovedElements locals:
A simple work around is to put the Repeater in its own Loader inside of the main loader, and periodical toggle the Loader's active property on and off, to force it to free the deleted elements without letting them pile up.