As a mitigation strategy we should prevent QmitkNodeSelectionButten to repaint if it is triggered due to a change of the "selected" property. That should prevent all (so far) known constelations that lead to the repaint based OpenGL errors.
Description
Description
Revisions and Commits
Revisions and Commits
| rMITK MITK | |||
| Restricted Differential Revision | rMITK1ea959aa2755 Fixed T27083 | ||
| Restricted Differential Revision | rMITKd34515785a4d Fixed T27083 | ||
| Status | Assigned | Task | ||
|---|---|---|---|---|
| Restricted Maniphest Task | ||||
| Resolved | None | T26741 Finishing new node selection concept | ||
| Resolved | floca | T23721 Project "Astonishing Angelfish" | ||
| Resolved | kalali | T23751 Introduction of new selection concept | ||
| Resolved | floca | T27069 OpenGL error / crash when opening context menu | ||
| Resolved | floca | T27083 Workarround for the OpenGL context menu crash |
Event Timeline
Comment Actions
But, you are right. This is a case I haven't thought of. And it is really a problem. I do not see any possiblity to detect this situation properly.
This leaves us with following options (as long as no solution comes up):
- Don't use the new selection widgets
- The widget do not actualize them self
- We cut the connection as listeners to prevent that propblem
I want to discuss it. For me #1 is not an option.
Comment Actions
Closed task and merged changes that optimized the thumbnail update of the selection widgets due to changes in the data.