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 _______________________________________________ gimp-developer-list mailing list List address: gimp-developer-list@xxxxxxxxx List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
