geert jordaens <[EMAIL PROTECTED]> writes:

> implement scrolling by changing the offset into the buffer was not
> my primary concern but a nice side effect.  My primary concern was
> to be able to render a larger buffer to be as acurate as possible
> for some plugin's and minimize influence by edge conditions.

We can keep the buffer outside the preview widget and only have it
create an internal buffer if no external buffer is supplied. The API
I have in mind is something like the following:

 * Set a pointer to an external buffer.
 * The buffer will be of type guchar* for now but using a gpointer
 * here allows us to continue to use this API when we introduce
 * 16bit support and/or floats.
void   gimp_preview_set_buffer (GimpPreview *preview,
                                gpointer     buffer,
                                gint         rowstride);

 * Write a row of data to the preview buffer.
 * The data is either written to the buffer set in a previous call to
 * gimp_preview_set_buffer() or if no buffer was set, an internal
 * buffer is allocated. This API exists mainly to provide an easy
 * migration from GtkPreview.
void   gimp_preview_draw_row   (GimpPreview    *preview,
                                const gpointer  data,
                                gint            x,
                                gint            y,
                                gint            width);

Of course we will want to encapsulate all this at some point, probably
be putting a GimpDrawablePreview on top of it. But I'd like to design
this thing from the ground up and make sure that it allows a smooth
migration from the current preview code.

For some slow plug-ins we will also need a way to indicate that the
preview is being redrawn. The API could look like this:

void   gimp_preview_set_progress (GimpPreview *preview,
                                  gdouble      progress);

"gdouble progress" is a value between 0.0 and 1.0.

I think we shouldn't waste screen estate for a progressbar but instead
draw a progress indicator in the preview area. Some sort of animation
that gives feedback to the user that the preview is being redrawn. As
soon as a progress of 1.0 or larger is set the progress indicator
stops and the buffer is shown (which should have been updated in the
meantime). Does that make sense? Does anyone have a good idea on the
animation to draw? I can imagine something like the Mac OS X busy
cursor (the b/w one, not the spinning rainbow). To implement this we'd
would need a PNG image with all frames of the animation side-by-side.
Shouldn't be too large, since we don't want to spend too much time
redrawing the progress indicator.

Gimp-developer mailing list

Reply via email to