> <200808162202.21281.michael.mcintyre@...> wrote:
> On Saturday 16 August 2008, Peter Plessas wrote:
> > >>> - Recording very much Midi data makes RG
> become slower and slower on
> > >>> screen redraws, the finally halting the
> whole program so that one
> > >>> looses recorded midi data. This happens
> on an otherwise powerful enough
> > >>> machine.
> > >>
> > >> I've never had this problem. How much is
> "very much?"
> > Like in that midi file:
> > (about 35000 notes within 4 minutes)
> What do I do with it, exactly? Load it and then start
> trying to record
> something on top of it?
> > You made me very happy with your reply to my comments.
> Isn't it great
> > that there is so much wonderful exchange going on in
> open source
> > software projects?
> We can agree on that too!
> > Aha, so the internal representation of notes is
> already done in respect
> > to notation? Or do you do the score rendering over
> again after the
> > shifting?
> I have to confess that I'm not completely sure I
> understand all of this
> myself, now that I've poked around and had a look. What
> I said about our
> storing notation-related properties with all events is
> true, but that isn't
> what's happening here at all.
> I'm doing an experiment. I loaded a MIDI file that
> contains an entire
> symphony in one file, which should serve well as an example
> of a "longer
> segment with many notes inside." I shifted one of the
> segments four bars to
> the right, and sure enough, it shut Rosegarden down for a
> long time. My CPU
> didn't go to 100%, and it didn't really affect
> anything else running on my
> computer, but it did shut Rosegarden's user interface
> down for the duration.
> It wouldn't repaint itself, or respond to input, and
> appeared to have gone
> I had to go back and do a full debug build to get a look at
> what was
> happening, and here it was. The move generated a few
> billion lines of this
> stuff, of which I've pasted just the end (forwarding to
> the devel list for
> further contemplation):
I haven't read any Rosegarden code, but will share what I know about "GUI hang" problems.
Generally speaking, when a UI operation causes the whole application, or the desktop GUI to "hang", or not response for along time, it is because of UI design problems.
For GUI to appear responsive, all GUI event processing are handled by a high-priority thread/process compare to other background, or even commandline textual interface processes. When a GUI even is triggered (mouse drag, button click...) the event processing thread calls the event handling function/method to perform the work for that event, all within that high-priority thread. If the function/method takes a long time, it can lock-out other lower-priority threads/processes. Since the event handling thread still has not returned yet, it cannot process any additional GUI events immediately (mouse click, keyboard events, graphic redraw for screen refresh...). That's the cause for the GUI not being responsive, and nothing else seems to work at that time, the application, or the whole system seems to "hang".
The software designer and programmer has to understand that. Any operation that may potentially take more than a couple of seconds being invoked from a GUI event should really be spawn off from the event handler into a different thread. If possible, the GUI should have a way to show the status of that particular operation being started, and again when completed.
Hope that helps.