Re: SOC - brush system

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

 



On 5/8/06, Simon Budig <simon@xxxxxxxx> wrote:
Philip L. (deathpudding@xxxxxxxxx) wrote:
> I'm considering creating a new brush system for the GIMP as part of the
> Summer of Code in order to make GIMP more suitable to digital painting.
> I've made some contributions to the project before, but it has been a
> while. Can anyone comment on how extensive changes to the rest of the
> codebase would need to be, how this would be affected by the future
> incorporation of GEGL

As for GEGL, I believe in your case it is pretty safe to ignore GEGL for
now and just work on the current model. You should keep your code that
generates the images that get pasted on the layer as generic as
possible, so that it can be changed to different pixel data
representations later (16-bit, floats, maybe other color models etc.)

When it comes to GEGL integration and a new paint core there has been
done some experiments in horizon [1]. Horizon was written with the
intent to be ported to GEGL, the way the airbrush and clone tool
(actually a cloning airbrush) was migrated to GEGL was that the core
operation of the brush,

stamp_brush (drawable, x, y, radius, opacity, hardness, color)

was devised in such a way that it could be done as an (in-place )
operation in a processing graph. Having seperated out the processing
in this way adding 16bpp / floating point support to horizon would
only need changes to the logic in the GEGL op and not in the code
calling it.

The GEGLification of horizon made the application too slow for it's
primary platform, the Nokia 770. The overhead is constant and will be
less of a problem on the desktop.

Another change that I hoped to achieve in horizon to see it's effect
on a painting core was the ability to record coordinates and thus
"replay" strokes. I never got quite around to this, but it allows for
more interesting changes and smoothing of the strokes. The problem
with such changes is that it adds even more overhead to the part of a
painting application that needs to be as responsive as possible.

1: http://pippin.gimp.org/horizon/

/Ø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