QTableView performance: slow repaint of scroll area viewport

SGaist

Hi and welcome to devnet,

If you sample code is a good substitute with what happens with your real application, you trigger a full repaint because you are telling the view that all cells have changed for all roles which is not the right thing to do.
There are some optimization that you can apply such as telling the view that you are using uniform height and that kind of things that helps.

svadym

@SGaist Hi and thank you for your feedback.

I've updated my emit dataChanged:

void updateRow(int row)
{
    if (row > rowCount())
        return;

    emit dataChanged(index(row, 0), index(row, columnCount() - 1), {Qt::DisplayRole});
}

Repaint time remains the same unfortunately. In any case, it's very good hint and will improve performance of my app. Thank you.

Regarding the uniform height: from what I saw QTableView doesn't have setUniformRowHeights. During the test I used the following configuration of the vertical header:

However, I'm not sure if it has the same effect. Or should I add Qt::SizeHintRole to my model and return fixed height?

svadym

As it was advised here, I've set fixed section resize policy for the vertical header:

#include "mainwindow.h"
#include "ui_mainwindow.h"

MainWindow::MainWindow(QWidget *parent)
    : QMainWindow(parent)
    , ui(new Ui::MainWindow)
{
    ui->setupUi(this);

    if (auto vheader = ui->tableView->verticalHeader()) {
        vheader->setSectionResizeMode(QHeaderView::ResizeMode::Fixed);
        vheader->setDefaultSectionSize(30);
    }
}

MainWindow::~MainWindow()
{
    delete ui;
}

void MainWindow::setTableModel(QAbstractTableModel *model)
{
    ui->tableView->setModel(model);
}

However, no changes in debug build. Thus, I can only assume that repaint is an actual bottleneck here, or I'm missing something else.

Christian Ehrlicher

Updating a model with 20Hz is not really useful - Noone will see this. Also update to a recent Qt version.

Pl45m4

@Christian-Ehrlicher said in QTableView performance: slow repaint of scroll area viewport:

Noone will see this

Fluent video picture motion for humans starts at around 24/25 Hz... so you can see changing values :) Still might not make too much sense to update the whole view.

svadym

@Christian-Ehrlicher fair point regarding 20Hz, but as I mentioned even if we update model every second, it's noticeable that UI "delays" for more than 50-100 ms. when you interact with it.

Regarding recent Qt version, I also have Qt 6.6.1 installed and it seems behave better when window/viewport is static. There are no expensive repaint events even if model emits dataChanged.

However, it still lags in debug build when I resize or change visibility of a main window:

Slow event detected: QEvent::Paint QWidget(0x235ac867ec0, name = "qt_scrollarea_viewport") "qt_scrollarea_viewport" 109
Slow event detected: QEvent::Paint QWidget(0x235ac867ec0, name = "qt_scrollarea_viewport") "qt_scrollarea_viewport" 109
Slow event detected: QEvent::UpdateRequest MainWindow(0xb3ce2ff620, name = "MainWindow") "MainWindow" 110
Slow event detected: QEvent::Paint QWidget(0x235ac867ec0, name = "qt_scrollarea_viewport") "qt_scrollarea_viewport" 173

Anyways, lagging during window resize in debug build is tolleratale. It's usable at least.

svadym

@Pl45m4 said in QTableView performance: slow repaint of scroll area viewport:

Still might not make too much sense to update the whole view

I'm emitting dataChanged only for updated rows and (now) only display role, so the update scope is limited)
The idea was to have smooth value changing (frame counts, cycle times...) when frames arrive under 100 ms. period for example. Otherwise, you could see value change in jumps/steps. In any case, it works well in release build, even with 20Hz model update frequency

My main concern was to know if it's expected behavior in debug configuration or there is just some problem in the way how I manage model and data updates.

Christian Ehrlicher

Please provide a minimal compileable example in a bug report with a recent Qt version. Also the OS is important. I never seen such slow times on machine here. MacOS has some issues but I don't care since I don't use it.

svadym

@Christian-Ehrlicher I can try to submit a bug report if you say that it's not normal.

Setup info:
Qt: 5.15.2 (MCVS 2019 32 bit), 6.6.1 (MCVS 2019 64 bit)
OS: Windows 10
Build: debug
Running from Qt Creator ("Run" button)

Christian Ehrlicher

@svadym said in QTableView performance: slow repaint of scroll area viewport:

I can try to submit a bug report if you say that it's not normal.

This would be nice. With a small reproducer (main.cpp only), a recent Qt version (6.9 and up) and some benchmark results from you. Also reduce the update rate to e.g. 10hz. It's fast enough - Noone can read that fast.