On Sunday 05 Oct 2003 3:52 pm, Silvan wrote: > You want to talk sluggish... Select all segments, then open a > notation view. I've been watching progress bars do their thing for > a full minute now, and it isn't done yet. OK, 1:53 to get the > notation view open.
Yes, now, this kind of thing exercises me more. A few seconds here or there to open a file is one thing, but two minutes to render some notation is a serious obstacle to using the program. Of course there's a limit to how much resource I want to divert to optimising this while it's usable for more modest files and there's still so much else to be done (and of course optimisation tends to take a lot of time). > WTF is up with all the counting, and then counting again, and then > counting again? Currently you get a separate progress sweep for each step of the rendering process -- layout for each staff, then reconciling bar lines across staffs, then rendering for each staff. It would be nice to merge them, but the resulting slow creep of the progress bar might jus t be too depressing for now. > Now you want to see some REAL sluggish behavior, hit the up arrow. > Transposing two three four blah... Transposing a whole staff is about as expensive an operation as you can get, because it usually causes every single note to have to move (because of the frequent accidental changes) and be re-rendered (because of accidentals and changes to beams, stems and leger lines). It's guaranteed to take as long as rendering the score in the first place, plus whatever time it takes to clean away the pixmaps that are being replaced. A lot of this is an unfortunate consequence of using the Qt canvas. A large proportion of the time spent in this phase is spent in canvas operations (creating, deleting and moving pixmaps), and because the canvas stores the whole of the rendered notation behind the scrolly window, that means we have to render the whole thing before it becomes usable at all. Practically any other notation program (including RG2.1) will render only the visible area at a time. Using the canvas makes it much easier for us to do collision detection and to scroll smoothly and rapidly once the rendering is done, but it makes the rendering both slow and heavily dependent on the length, complexity and number of the staffs. Brilliant ideas for optimisations here are always welcome. Chris ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Rosegarden-devel mailing list [EMAIL PROTECTED] - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
