The main rendering functino of GEGL is gegl_node_blit, gegl_node_blit
is in essence a
wrapper around gegl_buffer_get (), with a GeglNode instead of a
GeglBuffer, a currently unused
rowstride of the destination_buf, and the GeglBlitFlags describing the
caching behavior desired. The rowstride should probably be added to
gegl_buffer_get as well, keeping the current behavior of letting 0/-1
denote a default rowstride of bytesperpixel*width.
void gegl_node_blit (GeglNode *node,
GeglRectangle *roi,
gdouble scale,
Babl *format,
gint rowstride,
gpointer *destination_buf,
GeglBlitFlags flags);
void gegl_buffer_get (GeglBuffer *buffer,
GeglRectangle *rect,
gdouble scale,
Babl *format,
void *dest);
If the rowstride is going to be used it should be present in
gegl_buffer_get as well. The real problem is using either of these as
the primitive to build a zoomable panable display. Both of them are
implemented in such a manner that the GeglRectangle (x,y,width,height)
specifies the integer coordinates of the upper left corner to be
rendered to the linear buffer as well as the width and height of the
linear buffer and the scale argument specifies the scale to be used
during rendering 1.0 == 1:1, 2.0 means that each source pixel becomes
a 2x2 block of pixels etc. Using this API it isn't possible to request
rendering of arbitrarily positioned buffers since the upper left pixel
will always be fully rendered with the upper left edge at integer
coordinates.
Changing GeglRectangle to use floating point coordinates doesn't feel
like a solution since almost all other places where GeglRectangles are
used in GEGL it does literally mean a region of a raster in integer
coordinates.
Adding horizontal and vertical offsets to the functions would clutter
the API quite a bit.
What I think might be the best option will be making the scale be
applied to the buffer before the rectangle is taken into account at
all, and let this GeglRectangle specify integer coordinates of an
already scaled buffer making the region rendered be (x/scale, y/scale,
width/scale, height/scale).
Any comments?
/Øyvind K.
