On 1/9/06, Leon Brooks <[EMAIL PROTECTED]> wrote:
> OK, so what do Eric, Florent, myself and others here lurking who are
> interested in putting a rocket under GEGL need to do to get this show
> back on the road on a more permanent and ongoing basis?
> How hard is the storage code to write? Would it make sense to co-opt an
> existing storage management system from elsewhere? What can _I_ do? I
> code but am not a graphics guru of any sort.
The gegl code base needs cleanup, but the main problem I see with GEGL
is that since I have gotten involved GEGL has never actually been
processing images, if anyone could make GEGL actually process images,
even if it means just using linear buffers (perhaps by digging in CVS
for older versions that might actually have worked.). It would be a
great step for GEGL.
I am currently "thinking" about data storage management, this thinking
might take some time.
One aspect which is important when it comes to developing this code is
that it needs to integrate both with gegl, and gimp. Another issue to
keep in mind is that the API used to access the data storage system
will become the painful API needed to efficiently handle image data in
gimp/gegl, in much the same way that people need to familiarize
themselves with tiles when writing plug-ins for gimp. Keeping things
simple at the "end-developer-level" should be a goal.
There is existing code in the gegl/image directory is a previous
attempt at a storage model. I have failed to get a understanding of
how much of the problem is solved by the code in gegl/image, and
whether it has any shortcomings. I feel I do not have enough
experience with storage models to make a good decision, which is why I
am playing in a sandbox called horizon trying to figure some
aspects of it out with code that is actually processing pixels. The
data storage management in horizon is aiming high in an attempt to
discover as many possible requirements as possible.
I am developing horizon as the backend for a
sketch/scribble/paint/personal information storage system for a tablet
device from Nokia. The codebase is still under expansion and internal
api's haven't started to settle yet.
«The future is already here. It's just not very evenly distributed»
-- William Gibson
Gimp-developer mailing list