Slow text widget

[dracic]

The slow text widget is still present, and i did some research, so if anyone is willing to examine this.

Detailed suggestion can be found here

Investigation Report: Slow Text Widget Performance

1. Issue Summary

Users experience significant latency (2-3 seconds) when typing in text fields (MMFormTextEditor) within the mobile application. This makes data entry unresponsive and frustrating.

2. Investigation Methodology

• Code Path Analysis: Traced the execution flow from the QML frontend (MMFormTextEditor.qml) to the C++ backend (AttributeController.cpp).
• Performance Profiling (Static): Analyzed the computational complexity of functions triggered during text input.
• Web Research: Checked for known Qt/QML text rendering performance issues.

3. Root Cause Analysis

The investigation identified synchronous, heavy C++ logic execution on the main thread as the primary cause of the performance bottleneck.

3.1. The Hot Path

The following sequence occurs for every single character typed by the user:

1. QML Input: User types a character in MMFormTextEditor.qml.
2. Signal Emission: The textEdited signal fires immediately.

   // app/qml/form/editors/MMFormTextEditor.qml
   onTextEdited: function ( text ) {
       // ... logic ...
       root.editorValueChanged( val, val === "" )
   }

3. C++ Invocation: editorValueChanged is bound to AttributeFormModel, which calls AttributeController::setFormValue.
4. Heavy Recalculation: AttributeController::setFormValue updates the value and immediately calls recalculateDerivedItems.

   // app/attributes/attributecontroller.cpp
   bool AttributeController::setFormValue( const QUuid &id, QVariant value )
   {
       // ... set value ...
       recalculateDerivedItems( true, false );
       return true;
   }

5. Global Form Re-evaluation: recalculateDerivedItems is a resource-intensive function that:
   • Iterates through all form items (not just the changed one).
   • Constructs a QgsExpressionContext.
   • Evaluates QGIS expressions for:
     • Virtual fields (recalculateVirtualFields)
     • Default values (recalculateDefaultValues)
     • Rich text widgets (recalculateRichTextWidgets)
     • Tab visibility
     • Field visibility (item->visibilityExpression())
     • Editability (item->editableExpression())
     • Field names (item->nameExpression())
     • Validation (FieldValidator::validate)

3.2. Complexity

This process is effectively O(N) where N is the number of fields and expressions in the form. Since QGIS expression parsing and evaluation can be CPU-intensive, running this full cycle synchronously on the UI thread for every keystroke causes the observed freeze.

4. Discarded Hypotheses

• Qt Rendering/Layout Issues: While QML layout thrashing can occur, the magnitude of the delay and the direct correlation with the C++ expression logic strongly point to the backend calculation as the dominant factor. Simple text rendering in Qt Quick is generally performant enough for typing.

5. Recommendations

5.1. Immediate Fix (Recommended)

Implement Debouncing in QML:
Modify MMFormTextEditor.qml (and potentially other editors) to introduce a delay (debounce) before sending updates to the C++ backend.

• Approach: Start a Timer (e.g., 500ms) on textEdited. Only call editorValueChanged when the timer triggers or editingFinished occurs.
• Benefit: Reduces the frequency of recalculateDerivedItems calls from "per character" to "per burst of typing".

5.2. Long-term Optimization

• Dependency Graph: Instead of recalculating the entire form, build a dependency graph to only re-evaluate fields that actually depend on the changed attribute.
• Asynchronous Evaluation: Explore moving expression evaluation to a background thread, though this is architecturally complex due to QGIS/Qt threading constraints.

If this doesn't make any sense, just close it...

[tomasMizera]

Hi @dracic, thank you for reporting the issue and sorry to hear about the trouble. Can you please share the project with us? You can share it with workspace support and ping us then (see how to do it here: https://merginmaps.com/docs/misc/troubleshoot/#how-to-share-your-project-with-mergin-maps-support). This will help us profile the problem better.

Thank you for the detailed AI report too, it indeed works this way, but there are different reasons to do so. We'll try to reproduce the issue and find a good way forward.

Some additional questions:

• Do you also experience slowness in other parts of the app?
• Is this happening on a specific mobile device (which one?) or you see it on all of your devices (please specify some)?
• Some slowness can be caused by complicated QGIS expressions recalculation, do you use any?
• Android or iOS or both?

[dracic]

• Only text widgets
• Every mobile devices
• Just one concatenation of 3 fields, and few default value updates on edit
• Don't have iOS to check

[RastoHu]

The issue seems to be Android-only; iOS is fine.

[dracic]

I think it is simply more noticeable on Android due to IPC. This will obviously be visible on any form with more than approximately 20 attributes. However, the question remains—even in the case of a "smart form"—why would you catch every keystroke in a widget immediately?

Possible solutions:

While Typing: Completely disconnect the C++ backend. The user types into the QML text field; it remains purely visual, resulting in zero lag.

On Pause (The "Smart Form" Scenario): If the user stops typing for a set time (e.g., 500ms—"Debounce"), assume they have finished that thought. Trigger the C++ calculation then to update any potential live dependencies.

On Exit (The "Commit" Scenario): If the user types and immediately clicks "Next" or "Save," force an immediate update so no data is lost.

Personally, I would rather wait two seconds for an information update or search result than wait two seconds just to enter another letter.