On Mon, Nov 23, 2009 at 3:46 AM, Tim Chen <timchen@xxxxxxxxxxxxxx> wrote:
> Recently, I have spent my time reading source code of both GIMP and GEGL,
> and got few questions about GEGL and its future role in GIMP.
>
> 1. Why DAG in GEGL? Intuitively, say if we have two operations that are
> applied on two independent regions, they should be located in two separated
> sub-tree (sub-graph), so that we can save save some traverse time and
> potential redraw time.
Time spent on graph traversal is neglible compared to pixel computation time.
> However, it seems like that there is no such
> mechanism (correct me if I misunderstand the code) and all operation
> cache/reuse are determined according to the spatial relationship between the
> rectangle associated with the operations. If that's the case, won't a simple
> link-list suffice?
GEGL doesn't evaluate the full image at each evaluation, but only a
smaller region of interest (roi). This allows GEGL to compute the
minimall needed roi of the input nodes to reduce the amount of needed
computation, in addition caches might allow GEGL to skip some of the
pre-computation needed to satisfy the demands made by a single node.
> 2. Following question one, it seems like that GEGL has not been fully
> integrated into GIMP (2.7) yet, and I am wondering that for some common
> image manipulation case, say red-eye removal or skin smooth, what will the
> DAG in GEGL look like? Will it look like a tree with height of two
> (connecting all operations to the root display node) or a simple 1-D list?
One of the goals of GEGL integration in GIMP is to make GIMP be a non
destructive image editor. This means that instead of destructing a
layer (and saving the previous state in undo tiles), the layer will be
augmented with an operation that performs, and perhaps retains a cache
of the result for the operation(s) applied to it.
It is also possible, if I understand the idea you propose correctly to
feed the result of applying an application back to the original
buffer, this is what GIMP already does for its tentative GEGL
integration for the color tools.
> Ideally, how should GIMP build the graph to maximize the rendering
> efficiency?
This is yet to be determined, but ideally GIMP builds the graphs it
needs, and it is GEGLs responsibility to restructure and/or evaluate
them efficiently.
/Ø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
