When the projectable's size or image type changes, stop the idle
renderer and remove all queued update area because everything needs to
be re-rendered anyway. Also honor the projectable's offset when
invalidating the entire projection after clearing the pyramid.
The optimization here which would change only the group layer's offset
if the extents of the union of its children has not changed is
completely bogus. That case can only happen if one of the chldren was
moved in a way that does not change the extents of all children's
union, but this doesn't mean that the childrens' positions relative to
each other have not changed.
Instead, invalidate the entire projection to at least avoid constant
reallocation of the tile pyramid.
Found by group layer testing hero Tobias Jakobs.
(will have to optimize real translations of the entire group (or of the
only child in the group) differently)
Yes this is pretty lame, but we must prevent write access to these
items under all circumstances, and we have no other way but killing
the plug-in (it should not write to the drawable directly anyway)
Having a function that only abstracts whether there is an active
layer or not is pretty useless. This also doesn't make the code in
selection_generate_segs() more complex but rather more obvious.
When attaching/detaching a floating selection to/from its drawable,
connect/disconnect the floating selection's "update" signal and update
the drawable in the callback, because changes to the floating
selection affect the drawable and not the projection directly. Fixes
floating selection compositing in layer trees and is the right thing
to do anyway.
A floating selection is always the first layer in the image, but on
XCF loading it is attached *after* all layers are loaded, so the item
paths for child layers read from the XCF are off-by-one in their
toplevel index. Adjust them so everything loads as it should.
* app/xcf/xcf-private.h: add properties PROP_GROUP_ITEM and
PROP_ITEM_PATH
* app/xcf/xcf-save.c: when saving a group layer, save a
PROP_GROUP_ITEM. When saving a child item, save a PROP_ITEM_PATH
which contains the path indices returned by gimp_item_get_path().
* app/xcf/xcf-load.c: when loading a PROP_GROUP_ITEM, replace the
layer that is being loaded by a GimpGroupLayer, also ignore that
layer's hierarchy (it makes no sense to load the tiles of a layer
that's generated from its children). When loading a PROP_ITEM_PATH,
pass the loaded path up to xcf_load_image() so it can add the loaded
layer at the right place in the tree.
This is actually just an intermediate refactoring that uses
gimp_image_get_foo_list() inetad of get_foo_iter(), but it also
sanitizes saving the image's selection (it's now simply added to the
list of channels to save, instead of using some sick code to save it
in the same loop that saves channels), so i want to have this in a
separate commit from actual tree saving/loading.
The opposite of gimp_item_get_path(), just that it doesn't return an
item, it returns a parent item and an index that can be used to add
the item to an item tree.
As when loading channel props (which can replace the GimpChannel by a
GimpSelection), pass a GimpLayer** instead of a GimpLayer* to
xcf_load_layer_props(), so the function can replace the GimpLayer to
load by another type (e.g. GimpGroupLayer).
Add XCF property PROP_LOCK_CONTENT and save/load it for all layers and
channels. Vectors saving needs some refactoring here I'm afraid, so I
ignored it for now.
Use the new API whenever we want to determine the item's effective
lock state (whether we can write to the item's content or not). Use
gimp_item_get_lock_content() only in code that actually deals with
*this* item's locked state, which is only the PDB wrappers and GUI to
modify the flag on the item itself.
Michael Natterer