bitcoin: GUI event loop should be block free
When I created the bitcoin-qt GUI I made a big mistake in its design. I copied this more or less exactly from the wxwindows GUI. I was aware of this back in the day, but was planning to fix it later. I never got around to it. Honestly speaking I don’t think I ever will.
In any case, the event loop in the main thread of a Qt program (or any GUI program, for that matter) is never supposed to block. Any operation that can take non-trivial time (even in the order of 40ms) should be executed asynchronously.
We have many such cases; not only when the user does an explicit operation such as send, but also in response to internal notiications, and automatic periodic polls for new transactions, the current balance, and so on (these can take longer due to cs_main lock contention: worst during initial sync and when catching up). Also at the start of the application. Pretty much all communication with the node and wallet happens in the GUI thread itself.
This is more “redesign” than “refactor”, anyhow, and definitely not a “good first issue” it needs to happen at some point. Even more if we want snazzy animations in the android GUI.
(ref #17112 and plenty of other “GUI not responding” issues)
About this issue
- Original URL
- State: open
- Created 5 years ago
- Reactions: 6
- Comments: 16 (9 by maintainers)
Contributions to improve the GUI are always welcome.
after 4 years why not close this? obvious no one is going to fix it.
and the issue is still happening in 2024
Sorry for not being clear. The current bitcoin-qt is not going anywhere and so we should improve it where possible.
A GUI based on QML is another discussion that is unrelated to this issue. The project already exists at https://github.com/bitcoin-core/gui-qml.
I think that improvements to bitcoin-qt regarding this issue will benefit both multi-process and QML. It will benefit QML because the base code is the same.
I don’t see a reason to not improve in bitcoin-qt. Actually, it might be the best approach going forward with QML since by then the architecture is already oriented to async calls.
The major difference is that there is a separate thread for rendering the scene graph. There is still a moment where the main loop is blocked so that the scene graph is updated against the QML scene.
Using QML doesn’t magically fix this issue. The only way to fix this is to stop calling functions that can block (usually because mutexes are locked down the road or some heavy IO happens) from the main thread (the one that drives Qt event loop).
Going multi-process also doesn’t fix this, if some function blocks for IPC then the GUI will block.
hi, I have extensive experience with qt/c++/blockchain/bitcoin and can potentially tackle this a first issue.
i came here while working on a proof-of-concept for new bitcoin sidechain project and plan on decorating bitcoin-qt with custom functionality specific to that.
question1: given the bitcoin QT/QML project, is this issue still relevant? as Widgets and QML are really different GUI frameworks. Would it not be best to just jump straight to developing with QML and fixing the blocking issues there?
question2 is regarding the Process-Separation project, separating out QT from the core into its own process and communicated via IPC, really fundamentally changes the look feel responsiveness and overall proper design of the QT/GUI. if this process separation is something that we are committed to doing, maybe best to start there? and maybe even merge the two efforts into 1? separate the GUI into new QML in a new process?
as a side note, from my experience trying it both ways, ( my previous project started as a separate process, communicating via ipc to QT-Widgets, and a single process with QML) , the single process was the way to go. in fact we started with ipc/widgets and refactored to single process/qml.
#17135 is an approach that avoids blocking the GUI thread.
I’m not sure about it, I think it does require quite some idea of the inner workings (which is easy to underestimate if you’re familiar with the code base). Then again, if someone can pick this up as first issue all the better of them.
Article I linked to in the other issue https://doc.qt.io/archives/qq/qq27-responsive-guis.html describes more approaches in more detail, too.
I was about to ask how this could be solved, to give new contributors and reviewers an idea of the long term goal. Though it seems you mention two approaches in #10504. If they are applicable, we might want to tag this “good first issue”.
There’s also more written about this in #10504. I disagree that this is “definitely” not a good first issue. For someone with experience with GUI programming it could be a great first issue, because it requires little knowledge of bitcoin and can be implemented incrementally, in small prs targeted at specific parts of the UI.