Deferring layout of parts

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Deferring layout of parts

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.
Reply | Threaded
Open this post in threaded view
|

Re: Deferring layout of parts

wschweer9
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
> [hidden email]
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer
Reply | Threaded
Open this post in threaded view
|

Re: Deferring layout of parts

Marc Sabatella
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 <[hidden email]> 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
> [hidden email]
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer



--
Marc Sabatella
[hidden email]

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer