I'll need someone else to confirm this in the recent builds to see if it's still there, but in GIMP 2.8.8, I've found a small issue (tested on Windows XP).

Using the following arrangement of layers and parent-layers (GroupLayers), users can make the processor chug, and may experience unexpected behavior. Below, the prefix (X) means unlinked, and (L) will mean linked.

__[root image] (X)+--------BIG GROUP
(L)+--------+--------LITTLE GROUP
(L)+--------+--------+--------LITTLE LAYER ONE (L)+--------+--------+--------LITTLE LAYER TWO (L)+--------+--------+--------LITTLE LAYER THREE (X)+--------+--------BIG BACKGROUND LAYER (X)+--------ROOT BACKGROUND LAYER

Upon using the move-tool on any "grabbable" pixel of a linked layer (via move's "Pick a Layer or Guide" option), and trying to drag in some direction, the linked layers will drift apart or reset to arbitrary positions, independent of eachother.

This is contrary to the way that linked layers should behave, and ostensibly uses unnecessary processing as well, as program stability and responsiveness seems to decrease as this action is performed. This is probably an artifact from before GroupLayer was an option, back when all layers in link-mode could be handled uniformly.

To resolve this issue, I imagine checking for *contained-by* and *contains *relationships,
and doing more work when the user sets or unsets the "link" option for layers would solve the problem. If this operation takes noticeable time, it could be done first either when a transformation involving the linked layers occurs, or when the dockable Layers-pane looses focus following a period of link-toggling by the user there. It might remain stored until a delete or link-settings change occurs again.

Regards

On Fri, Aug 29, 2014 at 1:22 PM, Seldom Needy wrote:

I'll need someone else to confirm this in the recent builds to see if it's still there, but in GIMP 2.8.8, I've found a small issue (tested on Windows XP).

Using the following arrangement of layers and parent-layers (GroupLayers), users can make the processor chug, and may experience unexpected behavior. Below, the prefix (X) means unlinked, and (L) will mean linked.

__[root image] (X)+--------BIG GROUP
(L)+--------+--------LITTLE GROUP
(L)+--------+--------+--------LITTLE LAYER ONE (L)+--------+--------+--------LITTLE LAYER TWO (L)+--------+--------+--------LITTLE LAYER THREE (X)+--------+--------BIG BACKGROUND LAYER (X)+--------ROOT BACKGROUND LAYER

Upon using the move-tool on any "grabbable" pixel of a linked layer (via move's "Pick a Layer or Guide" option), and trying to drag in some direction, the linked layers will drift apart or reset to arbitrary positions, independent of eachother.

This is contrary to the way that linked layers should behave, and ostensibly uses unnecessary processing as well, as program stability and responsiveness seems to decrease as this action is performed. This is probably an artifact from before GroupLayer was an option, back when all layers in link-mode could be handled uniformly.

To resolve this issue, I imagine checking for contained-by and contains relationships, and doing more work when the user sets or unsets the "link" option for layers would solve the problem. If this operation takes noticeable time, it could be done first either when a transformation involving the linked layers occurs, or when the dockable Layers-pane looses focus following a period of link-toggling by the user there. It might remain stored until a delete or link-settings change occurs again.

Regards

For the record, I've added this to the tracker via at https://bugzilla.gnome.org/show_bug.cgi?id=735906 Report includes a file which should allow the error to be recreated.