On Sun, Aug 29, 2010 at 12:39 PM, Jacopo Corzani <corz...@gmail.com> wrote:
>> As he observes, this avoids the problem of 'adjustment layers' not
>> actually being layers in any normal sense (that is, their lack of
>> content) while allowing the same or greater functionality.
> This kind of layer's effect stack is currently under develpment (you
> post is dated to may 2007)? . It can be a great step to make gimp
> totally non destructive and easy to use.If this feature is under devel i
> would contribute in a development or test phase. Anyone know
> anything?There is an open task about that?
There is an ongoing architecture refactoring of GIMP towards migrating
the internal representation of buffers (or rather what is
traditionally seen by the user as layers) and
all processing happening on them to use GEGL (http://gegl.org/). An
initial refactoring has been done for color processing tools and the
processing of the layer stack. This can be enabled by the user through
the menus of the development version.
Once GIMP uses GEGL by default for the composition of the layers
adding any GEGL based operation as a filter on a layer is easy from a
programming perspective. I have myself done an experiment where I
replaced the per opacity slider in the layers dialog with a gaussian
blur and it works as expected for both text and other layers.
The UI for this is not fully decided upon, and when it comes to the UI
side and this proclaimed "layer-abuse", I am personally in favor of
adding adjustment layers within the layer tree. This keeps the flow of
compositing in one place in the UI, making it more readable. The
styling and interactions with these operations can be a bit different
from the actual content layers, allowing to collapse the list,
simplifying the layers dialog to a tree of just the "content layers".
Having this chain embedded within the layer tree solves an otherwise
problematic recursion issue if the list is kept external to the layer
tree, you want to be able to use layer subtrees as masks/parameters
for operations performed on a layer or layer-group. Note that the
transition to GEGL would also also enable you to use other render
nodes in addition to text like gradients, noise, fractals,
checkerboards, vector layers and more.
Thus helping out with this refactoring, and improving both GEGL and
how GIMP uses GEGL is probably what would be most beneficial.
One thing that probably would aid in accelerating the refactoring of
various subsystems is adding a tile backend to GeglBuffer that is
backed by a GIMP TileManager, This would simplify the code used during
transitioning, at the moment proxy GEGL operations are used that both
makes more code required and also adds some overhead that could be
Gimp-developer mailing list