OK, that makes sense. Oh well, it was a nice idea :-) lasconic once
suggested using a background thread for this, but I guess that would have
the same issues.
Marc
On Wed, Feb 11, 2015 at 2:52 AM, Werner Schweer <[email protected]> wrote:
> 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
>
--
Marc Sabatella
[email protected]
------------------------------------------------------------------------------
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
