'Performance problems with showing large text files using TextArea and ScrollView

Use case: I would like to show large log files (8k+ lines) using QML or at least QML-compatible components. Features like multi-line-selection, copy and syntax highlighting are mandatory.

Problem: The default approach would be using a TextArea inside a ScrollView but the problem is the high memory usage(on my machine with multiple lines selected: 2GB+) causing freezes(5sec+) and crashes.

Example code:

import QtQuick 2.12
import QtQuick.Controls 2.5
ApplicationWindow {
    visible: true
    width: 640
    height: 480
    title: qsTr("TextEditTest")
    ScrollView {
        id: scrollView
        anchors.fill: parent

        TextArea {
            id: textArea
            text: " "
            renderType: Text.NativeRendering
            textFormat: Text.PlainText
            placeholderText: "no text found"
            readOnly: true
            selectByMouse: true
        }
    }
}

(Just insert some text(8k+ lines) into the " ")

Question: Is it possible to improve the memory usage of TextArea + ScrollView? Or is there an alternative?

Possible solution?: Still use TextEdit but providing an own scroll function which loads the text on demand preventing rendering the whole text at once. The Problem is that I would have to write my own selection and copy features on top of the existing ones.



Solution 1:[1]

This comment from Jira sums up the problem and provides a possible solution:

Qt Quick's TextEdit will actually populate the scene graph with nodes for all glyphs, not just the visible ones. There is logic to isolate updates as much as possible, but all the geometry for all text has to be processed at least once and uploaded to the GPU, and draw calls will be generated for it.

So bottom line is that TextEdit is not suitable for texts at this size at the moment. Until this has been addressed, I would recommend to use a QQuickPaintedItem and QTextDocument instead.

Solution 2:[2]

This component is a QML port of QScintilla, it's better suited for very large files.

Sources

This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.

Source: Stack Overflow

Solution Source
Solution 1 Mitch
Solution 2 Philip Van Hoof