search

LMMS / lmms

Cross-platform music production software
https://lmms.io
GNU General Public License v2.0
8.14k stars 1.01k forks source link

Performance: Slow MIDI import due to message being shown repeatedly #2028

Closed michaelgregorius closed 9 years ago

michaelgregorius commented 9 years ago

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:

  1. 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.
  2. 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?

Wallacoloo commented 9 years ago

I don't deal with midi files enough to know if it's worth leaving the message in under interactive mode or not, but if you do leave the message in interactive modes, I agree with your decision to use option 1 over option 2.

Especially seeing as how AutomationPattern is in the core and not the gui, AutomationPattern should really be totally unaware of the existence of the gui's textFloat class.

tresf commented 9 years ago

Closed via #2033