Øyvind Kolås wrote:
* Daniel Rogers <daniel@xxxxxxxxxxxxxxxxx> [040115 20:58]:
There is no reason that an op has to be associated with a particular
In fact, multiple users may want different ROI's computed from the
op simultanously! Clearly, the ROI should be assocated with the
resultant image.
GeglImage* gegl_graph_get_image(roi_rect, other_rendering_parameters
(antialising hints, etc)).
And a GeglImage object is immediately returned. This GeglImage object
doesn't actually contain tiles, it just behaves like a BufferImage, and
retrieve tiles from the underlying op as soon as you request a tiles using:
gegl_image_get_tile(image,tileX,tileY,hints)
-Sytactic equivlence (Differences between ops and images)
First of, this method means there is no sytactic difference between
files, network sources, and in-memory tiles. It makes the node
construction api simplier.
Further, an op can (though it doesn't have to) do away with things like
bounds. And image, when connected to an op, has bounds, a specific
context in which it was rendered (say, with antilaising, a resampling
algorithm, or with a particular resolution), to which the op should know
nothing about.
-Ease of passing hints
There is a well defined way of passing hints to the rendering system.
The hints are able to be passed exactly when they are needed (and thus,
when they are known).
-multiple simultanous renderings
Using this method, a user could request several images from the graph
(essentially queueing up multiple renderings) and the rendering system
can take care of minimizing the amount of recaculations needed. This is
especially useful, because it is trivial to extend this api to support
resolution independence. (simply allow one to specify the rendering
context to the get_image function).
because a layer is not always a collection of pixels. Sometimes it is a
text layer, or a vector layer, or an adjustment layer, or an effect
layer. Ignore that thing about gegl-buffered-image. It was confusing
and not what I meant.
Effect and adjustment layers don't actually belong in this category of
"faucet" or provider nodes, nodes that somehow conjure up the
information about what pixels are contained without having image data as
inputs to themselves,. all the pixel values are decided by the
parametes, (filename, coordinates, color etc.)
I didn't say they did, but "layer" up there meant a GimpLayer, not any
gegl concept. A gimp layer is already at least two nodes (a leaf node
and a compositing node). It is not unreasonable to let a layer also be
one node. It just means that some layers are not editable, which is a
desirable feature anyway.
There certainly is a need for there to be a certain kind of
image that is capable of participating in operator caches, yes,
but wont you want to have many different ops writing to a
drawable?
Right, and the best way to handle that is with an op that can produce
multiple, writable images, or that has procedural drawing calls.
Requsting an image from an op is a way of specifing that you are
interested in manipulating that region. The op can handle all the magic
of locking minimal regions.
The example I think we should think about when discussing this is
something as essential to gimp as the paintbrush,. ideally in a totally
GEGL'ified world, how does the paintbrush work? Here is what I think:
Global compositing graph of a image in gimp, containing just one layer,
I've thrown in a thumbnail for the layer to be rendered as well for good
measure,. (and yes I think a processing graph should be allowed to have
more than one output,. since images can be reused, this is a very
natural extension of the API, allowing, when used for video to
simultanously display a image in a window on screen, and encoding a
mpeg4 stream to broadcast on the net, or save to file)
thumbnail
\
scale( 0.05)
\
display \
\_____\
\
mem_buf( GeglImage *buf)
When a stroke is started, I envision the graph to temporarily be changed
into:
thumbnail
\
scale (0.05)
\
display \
\_____\
\
stroke( M 20 20, L 20 40)
\
mem_buf( GeglImage *buf)
essentially a rendering op, where the Lineto coordinates grow with
interaction, and that part of the op is redrawn continusly as the user
moves the mouse.
Ahh. Before, I was considering why exactly you would want to modify the
graph in such a way, but I see now that you are considering the graph to
be creating a set of moving frames, and the initial stroke is an
animated parameter. I can see this as a reasonable, but contrived
solution, as this is not the behavior of the paintbrush in the gimp.
There is no reason to need the continual redrawing for normal paintbrush
actions. As soon as you have two points from the mouse you can start
drawing. You don't need to worry about those points changing again, so
there is not reason to go to all that effort to animate them.
Otoh, in the situation where you are drawing vectors, then yes, you want
the points to follow the mouse, but that is still not a problem, because
with vector layers you link it to a specific op which is responsible for
maintaining a list of vectors and you can maniplulate the stroke as a
set of vectors and the invalidation flows naturally from that.
An alternative is to accumulate all the calls, and trust the caching to
work out in such a way that we won't run out of memory,. but at some
point merging the strokes into pixel values is needed,..
Well, as long as you are not animating strokes (and you are not if you
are acumulating calls) then you don't need to worry about running out of
memory (though given the above notes, I am not sure you need to worry
about it in the other case either).
--
Daniel
