Sven
ignore the previous posting
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);
Sounds fine to me.
(IGNORE BAD IDEA However if possible a internal buffer in the preview window and the rendering function writing to it
would allow redrawing of the preview widget during the rendering process. This would give also some visual feedback on what the rendering function is doing. )
wasn't thinking clear this would mean updating all rendering functions.
makes sense. a litle remark though the *_draw_row usualy itterates over an already rendered buffer.
/** * 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.
Maybe it's even more simple when migrating from GtkPreview to use the gimp_preview_set_buffer API.
The external buffer sounds fine to me.
I'll trust You when You say that Mac OS X has nice busy cursors (don't know)
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.
Geert
_______________________________________________ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
