The MIDI import is quite slow due to TextFloat::displayMessage being called repeatedly in AutomationPattern::addObject.
An example MIDI that can be used to reproduce the issue can be found at http://www.vgmusic.com/music/console/nintendo/wii/mkwii-koopacape.mid (please also refer to #1971 for further sources). If you comment out the call to TextFloat::displayMessage performance improves quite a lot.
I assume that the current implementation of AutomationPattern::addObject was originally meant to be used in interactive cases where the user wants to create a connection that is already there and that it was not meant to be called from "non-interactive" code like the MIDI import.
The simplest solution might be to remove the message altogether. In my opinion even in an interactive case the information provided by the displayed message is not really useful to the user. If the user connects something that's already connected the system should simply do nothing because in the end it would still have the same effect that the user intended.
If the message should be kept for interactive cases there are two ways I can think of to improve the performance for the MIDI import case:
- Let
AutomationPattern::addObject return a boolean that indicates whether the model was added and remove the call to TextFloat::displayMessage. In case the model is not added the caller may decide what to do. In an interactive context the message could still be shown whereas in an non-interactive context, e.g. the MIDI import, the result is just ignored and no message is shown.
- Add a
boolean parameter to AutomationPattern::addObject which indicates whether it's called from an interactive context which means that the message should be shown or a non-interactive context which means that no messages are shown.
I would prefer the first solution because it keeps the usage of AutomationPattern::addObject more flexible, i.e. it would be simpler to implement some third, forth, etc. kind of behaviours in other callers. It also provides a better separation between presentation and functionality.
Any thoughts?
The MIDI import is quite slow due to
TextFloat::displayMessagebeing called repeatedly inAutomationPattern::addObject.An example MIDI that can be used to reproduce the issue can be found at http://www.vgmusic.com/music/console/nintendo/wii/mkwii-koopacape.mid (please also refer to #1971 for further sources). If you comment out the call to
TextFloat::displayMessageperformance improves quite a lot.I assume that the current implementation of
AutomationPattern::addObjectwas originally meant to be used in interactive cases where the user wants to create a connection that is already there and that it was not meant to be called from "non-interactive" code like the MIDI import.The simplest solution might be to remove the message altogether. In my opinion even in an interactive case the information provided by the displayed message is not really useful to the user. If the user connects something that's already connected the system should simply do nothing because in the end it would still have the same effect that the user intended.
If the message should be kept for interactive cases there are two ways I can think of to improve the performance for the MIDI import case:
AutomationPattern::addObjectreturn a boolean that indicates whether the model was added and remove the call toTextFloat::displayMessage. In case the model is not added the caller may decide what to do. In an interactive context the message could still be shown whereas in an non-interactive context, e.g. the MIDI import, the result is just ignored and no message is shown.booleanparameter toAutomationPattern::addObjectwhich indicates whether it's called from an interactive context which means that the message should be shown or a non-interactive context which means that no messages are shown.I would prefer the first solution because it keeps the usage of
AutomationPattern::addObjectmore flexible, i.e. it would be simpler to implement some third, forth, etc. kind of behaviours in other callers. It also provides a better separation between presentation and functionality.Any thoughts?