Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

UI is unresponsive for seconds at the end of dlt load #576

Open
vifactor opened this issue Nov 12, 2024 · 5 comments · May be fixed by #606
Open

UI is unresponsive for seconds at the end of dlt load #576

vifactor opened this issue Nov 12, 2024 · 5 comments · May be fixed by #606
Assignees

Comments

@vifactor
Copy link
Collaborator

vifactor commented Nov 12, 2024

Long running MainWindow::reloadLogFileFinishFilter() is executed in main thread and hangs UI
In particular, this code

QList<int> list = dltIndexer->getGetLogInfoList();
is long running

@vifactor vifactor changed the title UI is unresponsive fo seconds at the end of dlt load UI is unresponsive for seconds at the end of dlt load Nov 12, 2024
@vifactor vifactor self-assigned this Nov 23, 2024
@vifactor
Copy link
Collaborator Author

This

QThreadPool::globalInstance()->start([this] {
helps to avoid UI freeze, but unfortunately it is not thread safe as far as I can see and currently emits a lot of warnings.

The real fix as I can see it will include significant refactoring of the MainWindow::contextLoadingFile function.

@vifactor
Copy link
Collaborator Author

vifactor commented Nov 27, 2024

Refactored code a bit here: https://github.com/COVESA/dlt-viewer/tree/populate-ecus-nonblocking

Apparently, parsing messages (can easily be run in a separate thread) takes much less time than populating the tree, i.e. constructing and updating UI elements (supposedly main thread-only task)
getLogInfoMessages took 196 ms
populateEcusTree took 4309 ms

@vifactor
Copy link
Collaborator Author

@alexmucde currently when I import 2 dlt files sequentially, in the logs table only the logs from the second file become seen. I would expect that in such case the ECUs tree from the "Config"-tab should correspond to the latest imported file. This doesn't however happen, the ECUs tree gets appended as far as I can see, so it contains ECUs data from both files. Is this bug or feature?

@alexmucde
Copy link
Collaborator

@vifactor Issue solved and integrated, can be closed?

@vifactor
Copy link
Collaborator Author

@alexmucde issue is not resolved, the PR you merged is a little improvement. The real fix is more complicated, I have a draft for it, but needs cleanup. Please keep this issue open

If possible, could you give me the answer for the question above: #576 (comment) ?

@vifactor vifactor linked a pull request Dec 23, 2024 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants