On 10/27/07, Valerie VK <[EMAIL PROTECTED]> wrote:
> So... Gimp currently has 4 major goals?
> - Cairo
> - GEGL
> - Add named parameters and default values to the PDB
> - 6 months development cycle.
> Wouldn't it be easier to treat them as Separate goals for separate
> releases? Once Cairo and GEGL (I have no idea for the Parameters feature,
> so apologies for not being able to say more about it) have been properly
> implemented, Gimp should have the foundations for rolling out features
> more quickly. Wanting two at the same time though seems to be asking too
> much, and proper implementation of GEGL in my opinion justifies one final
> long development cycle.
> Maybe something like this can be considered:
> Gimp 2.6:
> - implementation of Cairo (get this out of the way)
> - start background work on GEGL, by dedicating more developer resources
> (if possible) to actually coding GEGL without necessarily implementing it
> yet

Okay I want to clear this up:
GEGL *is* coded (see www.gegl.org), and already in use by a few
different applications.
It works. Getting it working fast and bugfree, though (for instance,
good caching behaviour), will be driven by use in GIMP, which will
help to locate slow and buggy areas of GEGL.
Initial integration will probably be a fussy business, rather than a
particularly large one -- making sure that a) it's used right and b)
the parts that should use it, do use it.

The only major point for GEGL that is currently known that would make
integration with GIMP difficult, is 8bit-specific code; GEGL Ops that
accept and output 8bit integral RGBA instead of 32bit float RGBA. I
believe many of these can be created automatically by modifying the
current code, which already handles generating float versions of
porter-duff ops and blending ops. In the mean time, a single
conversion op (float -> 8bit int) could be made.

> - bunch of other easier features to keep people happy
> - development cycle: 6 months to a year.
> Gimp 2.8:
> - GEGL integration
> - the background GEGL work that started with Gimp 2.6 should have paved
> the foundations for slightly faster integration
> - the development cycle will probably still be long, but this will be the
> last "long" release cycle.
> Gimp 3.0+:
> - with GEGL properly implemented, from now on, development cycles will be
> 6 months.
> Once GEGL has been implemented, the following features seem to be the most
> demanded ones:
> - CMYK
> - 16 bit
> - layer effects
> - layer groups

It's worth a minute to point out the notable, and deserved, absence of
adjustment layers from this list.  People have had a few discussions
(here? certainly on bugzilla.) about this topic, and it arose that:
a) Adjustment layers are generally an ugly, complicated idea
b) They are also an unnecessary idea -- the combination of layer
effects and layer grouping can produce the same effects in a much more
sensible way.

(for the reference of anyone who was considering bringing this topic up ;)

> Any one of the above could justify a minor release. Having the first
> GEGL-version of Gimp ship with one of the above features would justify the
> time spent on it, especially if the developers explain that the other
> features will follow fast. Having said first GEGL-version of Gimp ship
> with Two of the above would be fantastic.
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
> _______________________________________________
> Gimp-developer mailing list
> Gimp-developer@lists.XCF.Berkeley.EDU
> https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Gimp-developer mailing list

Reply via email to