I experimented with deferred layout of parts, actually it was the first implementation. I got hard to solve problems with the undo/redo system. During layout elements (especially problematic segments) can be created. This does only work in the context of a command (startCmd() - endCmd()) so that the creation and deletion of elements gets recorded on the undo stack. Otherwise the undo stack can get inconsistent.
In the current implementation the rule is to change the score only in a command context and record all changes in the undo stack. In a future implementation i can imagine to not record changes to generated elements so that layout can happen outside of a command. For this to work right some problems must be solved. As an example add/remove segment works by using nextSegment() prevSegment() in the segment list to record the proper place for the (inserted/deleted) segment. If this elements change outside of a command then the next undo/redo will corrupt the segment list. Am 10.02.2015 um 20:40 schrieb Marc Sabatella: > At one point a while back, I decided to try implementing a scheme where > instead of always laying out all linked parts on every edit to the score or > any part, we would only lay out the score or part actually being edited. I > left the layoutAll flag set for the rest of the linked parts and forced a > part to update layout when it received focus (eg, when you switched tabs, or > clicked in a window when using the stacked/side-by-side document windows). > > It was a simple but effective hack, basically cutting the layout time in > half for scores with parts. You might worry there would be some sort of > side effect from not updating layout on each command, but if there were, I > didn't see them. > > The one thing I didn't do was find the places where we are outputting the > score in some fashion - print, save, export - and force the layout then. > There can't be that many places where this would need to be done, though. > > >From http://musescore.org/en/node/47106, I see we are considering a layout > optimization that would allow you to split up a large score with section > breaks only lay out systems within the current section. Fantastic idea. > Is it worth my also continuing the work I had started on deferring layout of > parts? I can imagine the answer being, no, not worth it for 2.0. But if > it's as easy as it was appearing to be, it's actually a pretty big win for a > pretty small change. > > > > -- > View this message in context: > http://dev-list.musescore.org/Deferring-layout-of-parts-tp7579105.html > Sent from the MuseScore Developer mailing list archive at Nabble.com. > > ------------------------------------------------------------------------------ > Dive into the World of Parallel Programming. The Go Parallel Website, > sponsored by Intel and developed in partnership with Slashdot Media, is your > hub for all things parallel software development, from weekly thought > leadership blogs to news, videos, case studies, tutorials and more. Take a > look and join the conversation now. http://goparallel.sourceforge.net/ > _______________________________________________ > Mscore-developer mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/mscore-developer > ------------------------------------------------------------------------------ Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ Mscore-developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mscore-developer
