Re: 2.6 roadmap items

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Nov 13, 2007 6:16 AM, Henk Boom <lunarc.lists@xxxxxxxxx> wrote:
> On 12/11/2007, peter sikking <peter@xxxxxxxxxxxx> wrote:
> > - GEGL vs. vector, where is the dividing line when in the
> >    future with GEGL  everything added to the image remains
> >    modifiable and removable?
>
> I'm not sure what the question here is, wouldn't vector layers only
> help this philosophy? As far as I understand their purpose is to avoid
> having to do permanent "stroke path" operations, instead making the
> shape easily modifiable and impermanent.
>
> > Somehow we need to find a balance here where trivial stuff
> > can be done in an obvious way within GIMP, we do not branch
> > out into specialised inkscape territory and come up with
> > something that fits the GEGL architecture.
>
> I see vector layers as being a replacement for most uses of the
> current stroke/fill path. It accomplishes the same thing, but has the
> advantage that you don't have to keep re-doing it when the path is
> changed, as it updates automatically.

When it comes to SVG integration with other applications, a layer tree
or similar based on GEGL would probably automatically support this
not much differently from how text layers would be supported, and the
SVG-loading operation for doing so is already in place.

I  plan to make an experimental stroke-history based paint engine on
top of GEGL. Doing experiments with this is soon becoming possible
since the caching infrastructure I've been adding to GEGL in the last
half year seems to be getting solid enough. This would work  by storing
stroke path, pressure, tilt etc information along with the brush settings
for every stroke in a sequence of operations that apply paint/dabs to the
underlying drawable. Each ops would contain it's own cache to speed
up the application of another stroke on top (this per-node/op caching
infrastructure is getting it's final polish for the next GEGL release). This
will allow editing the properties of the strokes of a regular paint tool, and
even removing an individual stroke after it has been made. The interesting
question to be answered when a prototype is mocked up is whether it will
be responsive enough for interactive painting.

/Øyvind K.
-- 
«The future is already here. It's just not very evenly distributed»
                                                 -- William Gibson
http://pippin.gimp.org/                            http://ffii.org/
_______________________________________________
Gimp-developer mailing list
Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


[Index of Archives]     [Video For Linux]     [Photo]     [Yosemite News]     [gtk]     [GIMP for Windows]     [KDE]     [GEGL]     [Gimp's Home]     [Gimp on GUI]     [Gimp on Windows]     [Steve's Art]

  Powered by Linux