Hello,

This is just a random thought off the top of my head, but maybe it will inspire someone...

It would probably be very cool if the "preview" functionality could be implemented so that it could also act as a filter.

Such that, for instance, someone could grab a "looking glass" and "attach an effect" to it and move it over the image area. The image within this "looking glass" would then show a preview of the effect in this area in pseudo-realtime.

Maybe if the design is made with this in mind it would make for a very useful bit of code where a 'preview' is simply a copy of the image or layer with a fixed 'looking glass' size and a couple scrollbars.

And it would make for some very powerful effects, perhaps even to the extent of having 'effect layers'.

Or not.

Food for thought, Chris

I think come up with a simple preview widget is the way to go. At least all people willing to
add preview's could start doing it the same way.

What I've seen from plugin's is that they are frequently using pixel regions to render images.
If the pixel region isn't generic enough the I would start with the functionality described from the current tutorial on the GimpPreview by Ernst which would be a little more work to implement in some plugin's. Although I think you should be able to render a bigger preview area than the displayed area.

Writing a callback for the preview

When the preview want the plug-in to render a new image it will call a callback function in your plug-in. In most cases you should be able to use the following:

static void render_callback (GtkWidget * widget, GimpPreviewUpdateEvent * event, gpointer data)
{
GimpPreview *preview = GIMP_PREVIEW (widget); GimpDrawable *drawable = (GimpDrawable *) data; GimpDrawable *dest_drawable;
GimpPreviewProgressUpdater preview_progress_updater;

/* Get a scratch drawable */ dest_drawable = gimp_preview_get_temp_drawable (drawable, event->image_x, event->image_y, event->image_width, event->image_height);

/* Initialize the GimpPreviewProgressUpdater */ gimp_preview_progress_updater_init_for_preview (&preview_progress_updater, preview); /* Render to the scratch drawable */ render (drawable, dest_drawable, event->image_x, event->image_y, event->image_width, event->image_height, &render_params,
&preview_progress_updater); /* Draw the scratch drawable on the preview */ gimp_preview_draw_unscaled_drawable (preview, dest_drawable); /* Delete the scratch drawable */
gimp_preview_free_temp_drawable (dest_drawable); }

staring from the back.

Again, sorry, but I don't understand this. What's the displayed area? What do you mean when you say "render"

We are talking about a preview therefore the (displayed)preview area is the area that is visible to the user. Will use in for further explanation "preview buffer" to indicate the non visual area.
When I say render I mean the computation of the visual effect. When I say draw I mean the visualisation of the computed effect on the preview area.

Sorry, I am not sure if I get what you are saying here. Could you elaborate a bit, perhaps give an example of the API that you think is needed?

A minimum for the preview widget would be :

Widgets : 1. The preview area
2. Horizontal/Vertical scrollbars if needed.

Signals : 1. preview_draw : draw preview area from current preview buffer. 2. preview_update : Call-back for rendering function followed by preview_draw or call preview_draw from callback. (if possible send signal preview_draw from within callback to display rendering progress). 3. preview_changed : Call-back to determine which part of the drawable that must be rendered for preview.
(after scrollbar position changed)

API :

1. new_preview_buffer(drawable, buffer, x,y ,width, height, offset_x, offset_y);

drawable = self explanatory buffer = type to determine
x, y = offset from drawable origin width, height = self explanatory offset_x, offset_y = offset for preview buffer.

drawing origin = 0,0 preview origin = 0+x, 0+y
x,y=128
width, height = 128
offset_x, offset y = 0 (preview buffer = preview area) => rectangular preview buffer = (128,128) , (256,256)
offset_x, offset_y = 20 use to render the preview more accurate. (preview buffer > preview area)

=> rectangular preview buffer = (x1-offset_x, y1-offset_y) , (x2+offset_x, y2+offset_y)
= (108,108), (276,276)

2. function to draw the buffer.

preview_draw_buffer(buffer);

3. function to free buffer preview_free_buffer(buffer);

4. functions to for internal housekeeping that can be used in the callback from preview_changed.
calculate new limits, check if buffer covers new coordinates if not preview needs update, otherwise only draw from buffer.

Geert

Sven Neumann wrote:

Hi,

geert jordaens writes:

A minimum for the preview widget would be :

Widgets : 1. The preview area
2. Horizontal/Vertical scrollbars if needed.

agreed

Signals :
1. preview_draw : draw preview area from current preview buffer. 2. preview_update : Call-back for rendering function followed by preview_draw or call preview_draw from callback. (if possible send signal preview_draw from within callback to display rendering progress). 3. preview_changed : Call-back to determine which part of the drawable that must be rendered for preview. (after scrollbar position changed)

I don't think any of this should be part of the GimpPreview widget. IMO it's the plug-in's job to push the pixel data to the preview, not the preview's job to request it. Such a framework can be added later as I outlined in the proposal I just sent to the list.

our posts corssed, agree with You that it can be added later.

The preview widget itself doesn't need to know about the drawable it previews, nor what part of it is previewed. It just displays a buffer the size of the preview and that's it.

as does GtkPreview now, works for me.

Perhaps we optionally need an API that allows to keep the buffer outside the preview widget. That would allow the plug-in to render a larger version and implement scrolling by changing the offset into the buffer.

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.

Geert

Sven

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. 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.

/**
* 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.

makes sense. a litle remark though the *_draw_row usualy itterates over an already rendered buffer.
Maybe it's even more simple when migrating from GtkPreview to use the gimp_preview_set_buffer API.

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.

would be nice, I would prefer to redraw the preview from the buffer reglary if possible.

Geert

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.

/** * 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.

makes sense. a litle remark though the *_draw_row usualy itterates over an already rendered buffer.
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.

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.

I'll trust You when You say that Mac OS X has nice busy cursors (don't know)

Geert

On 22 May 2004, Sven Neumann wrote:

So this API would allow you to queue a redraw even after the buffer is only halfway written. Of course you would also have to run the main loop for the redraw to actually happen. Anyway, I consider this rather bad style. IMO, if the preview takes considerable time, then it shouldn't be shown halfway done but instead the progress API should be used to draw a progress indicator in place of the preview. What do others think?

There are a lot of image applications that perodically update the preview. In fact, this is essentially what the gimp color balance tools do -- load a large image and adjust the sliders intermittantly and you can watch the previews go by. There are good arguments for incremental update, and good arguments for a progressbar. Superimposing a busy cursor over the preview or replacing it with a progress indicator makes judging between slight differences in the settings harder.

But I think the real issue here is that slow previews should be computed in small chunks in an idle handler so as to not impede interactivity.

Rockwalrus

On Fri, 2004-05-21 at 21:57 +0200, Sven Neumann wrote:

[Thanks for CCing me on this, Sven; I don't follow gimp-developer as closely as I would like these days]

There seem to be a couple of options. Let me try to summarize the ones that I see:

- Use GtkPreview.

GtkPreview is declared deprecated by the GTK+ team and we will want to get rid of it at some point. On the other hand there isn't really a good reason not to use it. The API does it's job w/o and I never understood why it as deprecated in the first place.

The GIMP should get rid of GtkPreview as soon as possible. It is a deprecated API, and it is a horrible API regardless of its deprecation status. From the viewpoint of the GIMP and likely elsewhere, this is why it is horrible:

- It only supports a draw_row() API. This is very cumbersome for filters, which must generate a temporary buffer and then copy it row by row to the GtkPreview.

- It doesn't handle opacity information. Plug-ins must composite their images against a checkerboard or some other sort of background by hand.

- It doesn't handle scrolling, zooming, etc., which are very useful for previews in an image editor.

- Use a GdkPixbuf as the pixel buffer and use a GtkImage to display it.

The disadvantage is that the GdkPixbuf and GtkImage API are not too well suited for our needs. GdkPixbuf doesn't handle greyscale buffers and GtkImage can only display the full pixbuf. If we wanted to show only a region of the buffer we could work around this using gdk_pixbuf_new_subpixbuf() but IMHO this is becoming too hackish to consider it.

GtkImage is just a way to easily slap an image into a window, for example, to put an icon in a dialog box. It's not designed to display non-static images or those that need scrolling/zooming/etc.

GdkPixbuf is not meant to be *THE* one representation for images that all programs should use; it is just the representation that GTK+ understands. It also happens to be a convenient representation for simple programs as well; this is obviously not the case for the GIMP.

I'm not sure if the GIMP can use some of the interesting functions in GdkPixbuf such as the composite-on-checkerboard stuff --- you already have code in the GIMP to composite against checkerboards for image windows. But if you find any use in that code in GTK+, by all means use it.

- Come up with a full-featured preview widget.

We could use the widget that Ernst Lippe wrote but since there hasn't been any effort so far to discuss it's API again and to get it into CVS I am not sure if it makes sense to wait for this to happen.

This is the right way to go. I'd say the list of requirements for a preview widget for the GIMP are at least the following:

1. Have a way for the filter to specify whether the preview can zoom or not; this is for filters which are not scale-invariant. Still, special cases like blurring need to be able to zoom in and out, but cheat when computing the preview:

- scale the original image by 1/N - blur with a radius of 1/N pixels
- draw that as the zoomed-out preview

That is, it won't show exactly the same result as if you did

- blur the original image with a radius of N pixels - scale the result by 1/N
- draw that as the zoomed out preview

but it will be pretty useful anyway.

2. Be able to request rendering of only the previewed area, and only scrolled-in areas after that. Say the preview is (with, height) pixels large and it starts at offset (xofs, yofs). When the plug-in's GUI starts up, the preview emits a notification saying, "render the area at (xofs, yofs, width, height)". If the user then scrolls the preview by 10 pixels to the left, the preview should emit a notification saying, "render the area at (xofs - 10, yofs, 10, height)". That is, rendering of the preview should be incremental based on scrolling.

3. Normally the preview doesn't need to hand image data to the filter --- the latter already knows how to get it using pixel regions. Still, it would be useful to provide some sort of of

gimme_temporary_pixel_region_for_zoomed_image (image, zoom_factor, ...)

This is for filters which can display a zoomed preview and which don't need to process the original image data, like color mapping plug-ins.

4. Support resizing the preview. Previews with a fixed size of 128 pixels are not useful when you are a graphic designer with a wide-screen monitor.

5. Support automatic compositing of images with opacity information against a checkerboard --- this should just use the user preference for image windows.

I hope this is a useful starting point for designing an API. From what I saw, Ernst Lippe's code seems to handle a lot of this stuff already. It would be a lot easier to just resurrect that code and bring it up to date rather than to write something from scracth.

I don't think an API for super-slow filters is even worth considering. People should just learn to write faster code :)

Federico, who is to be blamed for the pathologically slow Diffraction filter

On Monday 24 May 2004 19:11, Federico Mena Quintero wrote:

This is the right way to go. I'd say the list of requirements for a preview widget for the GIMP are at least the following:

1. Have a way for the filter to specify whether the preview can zoom or not; this is for filters which are not scale-invariant. Still, special cases like blurring need to be able to zoom in and out, but cheat when computing the preview:

- scale the original image by 1/N - blur with a radius of 1/N pixels
- draw that as the zoomed-out preview

That is, it won't show exactly the same result as if you did

- blur the original image with a radius of N pixels - scale the result by 1/N
- draw that as the zoomed out preview

but it will be pretty useful anyway.

2. Be able to request rendering of only the previewed area, and only scrolled-in areas after that. Say the preview is (with, height) pixels large and it starts at offset (xofs, yofs). When the plug-in's GUI starts up, the preview emits a notification saying, "render the area at (xofs, yofs, width, height)". If the user then scrolls the preview by 10 pixels to the left, the preview should emit a notification saying, "render the area at (xofs - 10, yofs, 10, height)". That is, rendering of the preview should be incremental based on scrolling.

3. Normally the preview doesn't need to hand image data to the filter --- the latter already knows how to get it using pixel regions. Still, it would be useful to provide some sort of of

gimme_temporary_pixel_region_for_zoomed_image (image, zoom_factor, ...)

This is for filters which can display a zoomed preview and which don't need to process the original image data, like color mapping plug-ins.

4. Support resizing the preview. Previews with a fixed size of 128 pixels are not useful when you are a graphic designer with a wide-screen monitor.

5. Support automatic compositing of images with opacity information against a checkerboard --- this should just use the user preference for image windows.

I hope this is a useful starting point for designing an API. From what I saw, Ernst Lippe's code seems to handle a lot of this stuff already. It would be a lot easier to just resurrect that code and bring it up to date rather than to write something from scracth.

As far as I can see my preview widget can satisfy all of your requirements.

I don't think an API for super-slow filters is even worth considering. People should just learn to write faster code :)

That's not always possible. There are several classes of interesting algorithms, e.g. most image enhancement techniques, that are inherently slow. Also the fact is, that most current plug-ins are indeed not very efficient. But especially with slow algorithms you desperately need a preview. And even with a fast algorithm there will be cases when the user is probably faster, e.g. while scrolling or zooming a large preview image. So I certainly believe that slow algorithms are an important use case for the design of a preview.

Ernst Lippe

On Saturday 22 May 2004 14:54, Sven Neumann wrote:

geert jordaens writes:

Signals :
1. preview_draw : draw preview area from current preview buffer. 2. preview_update : Call-back for rendering function followed by preview_draw or call preview_draw from callback. (if possible send signal preview_draw from within callback to display rendering progress). 3. preview_changed : Call-back to determine which part of the drawable that must be rendered for preview. (after scrollbar position changed)

I don't think any of this should be part of the GimpPreview widget. IMO it's the plug-in's job to push the pixel data to the preview, not the preview's job to request it.

But the position of the previewed area and the current magnification are inherently properties of the preview itself. It seems pretty logical to make scroll and zoom buttons part of the preview widget and in that case it is the preview widget that will detect if the position or scale has been changed. So the most logical design is to let the preview call the plug-in algorithm and not the other way round. I can see nothing wrong with using signals in this case, because they are more flexible than the other standard solution of having call-back functions.

Do you really propose that the plug-in itself handles all the GUI interactions for scrolling, zooming and resizing and that it also is responsible for recording the current position and scale and size of the preview? This seems very unelegant, to say the least. Also how do you handle plug-ins that have multiple previews?

Such a framework can be added later as I outlined in the proposal I just sent to the list. The preview widget itself doesn't need to know about the drawable it previews, nor what part of it is previewed. It just displays a buffer the size of the preview and that's it. Perhaps we optionally need an API that allows to keep the buffer outside the preview widget. That would allow the plug-in to render a larger version and implement scrolling by changing the offset into the buffer.

How are you going to decide the correct size for this area? When you make it substantially larger than the previewed area the response to user actions will become slower. It will happen frequently that this buffer will become invalid, e.g. when some parameters of the algorithm have been changed, when the user zooms out, when the image is scrolled over a larger distance. The only case where such a larger buffer might be useful is when the user only scrolls by very small amounts and in my experience that does not occur often. So having a larger buffer makes the design of the plug-in more complicated (how should it determine the "right" size for this buffer), it will cause a performance hit on many normal preview operations.

Ernst Lippe

On Saturday 22 May 2004 22:40, Nathan Carl Summers wrote:

On 22 May 2004, Sven Neumann wrote:

So this API would allow you to queue a redraw even after the buffer is only halfway written. Of course you would also have to run the main loop for the redraw to actually happen. Anyway, I consider this rather bad style. IMO, if the preview takes considerable time, then it shouldn't be shown halfway done but instead the progress API should be used to draw a progress indicator in place of the preview. What do others think?

There are a lot of image applications that perodically update the preview. In fact, this is essentially what the gimp color balance tools do -- load a large image and adjust the sliders intermittantly and you can watch the previews go by. There are good arguments for incremental update, and good arguments for a progressbar.

For very slow plug-ins incremental updates are better, because the user can sooner detect and remedy any problems with the parameter setting or the correct scroll position sooner. It is especially useful during scrolling because it is frequently possible to determine from a small part of the new image if you are at the desired position or not. When the preview image only shows a progress-bar you loose this type of immediate feedback.

(In my current version of the preview incremental updating does not work, even though I call gtk_widget_queue_draw on it. Like Sven indicated, I would probably need to call back to the GLib main loop)

But I think the real issue here is that slow previews should be computed in small chunks in an idle handler so as to not impede interactivity.

Another very important issue is how these computations can be halted when the image that is being computed has become obsolete. In my experience this happens very frequently.

Ernst Lippe

On Tuesday 25 May 2004 14:57, Sven Neumann wrote:

Hi,

Ernst Lippe writes:

Do you really propose that the plug-in itself handles all the GUI interactions for scrolling, zooming and resizing and that it also is responsible for recording the current position and scale and size of the preview? This seems very unelegant, to say the least. Also how do you handle plug-ins that have multiple previews?

No, I want to use the GtkScrolledWindow API for the scrolling and the standard GtkWidget API for resizing.

What do you mean with the GtkScrolledWindow API? Do you want to actually use GtkScrolledWindow with some image widget inside it that shows the rendered image (that is pretty expensive when the rendered image is large) or do you just want to implement a new widget that has the same API?

I want to completely leave
scaling out of this first basic widget. It will allow us to get rid of GtkPreview and that's the main problem we need to solve now. Of course it's a good idea to think beyond that and I agree that we will need a more complex preview widget than what I proposed to start with.

But zooming is actually a pretty complicated issue, and it will have a profound influence on your API.

However this is all not finished and I am open for other ideas. Actually I am not too happy with the proposed API, especially the fact that the buffer is outside the preview and how scrolling would have to be handled. So I am perfectly willing to reconsider it.

What is the point about plug-ins that have multiple previews? I fail to see the problem; perhaps you can explain it to me.

The point is that when you maintain many important parameters such as size and scale outside the previews you will have to keep track of which data belongs to which preview and you will have to hunt around to find the neccessary data. This is messy.

I am currently trying to come up with a proposal for GimpDrawablePreview, an extension to the GimpPreview interface that should allow plug-ins to reuse their rendering function for the preview.

One of your main objections against my API was that it would require modifications to the rendering function (because I believed they were pretty minor, that was no problem for me but apparently you thought that this was unacceptable). As an alternative you proposed some alternatives, like temporary drawables and some global mode switch that caused all drawing operations to use a temporary drawable when that drawable was in "preview-mode".

When you insist that the rendering functions may not be changed at all, you will probably have to come up with something like this. Finding a framework that allows this, should be the major design challenge at this point. It will require some important changes in the Gimp core. This design item will have a very big influence on the preview's API. So why don't you tackle this point first? So far you have not presented a detailed design solution. Instead of finding some quick ad hoc solution for a few plug-ins I would say that it is much more important to get this one right. I am afraid that your proposals so far sounded like horrible hacks in my ears, but perhaps if would work them out in more detail I might be convinced otherwise.

Of course, when your real problem is how to add a nice functional preview to a few plug-ins, I know an easy solution :)

How are you going to decide the correct size for this area? When you make it substantially larger than the previewed area the response to user actions will become slower. It will happen frequently that this buffer will become invalid, e.g. when some parameters of the algorithm have been changed, when the user zooms out, when the image is scrolled over a larger distance. The only case where such a larger buffer might be useful is when the user only scrolls by very small amounts and in my experience that does not occur often. So having a larger buffer makes the design of the plug-in more complicated (how should it determine the "right" size for this buffer), it will cause a performance hit on many normal preview operations.

I agree but it certainly doesn't hurt to allow this kind of use. That's why I say that we need a simple but very flexible widget first. Most plug-ins will never use it's API but access it on a higher level. But if a plug-in wants to do non-standard things, then it shouldn't have to start with a GtkDrawingArea again.

But an API where the preview simply tells the plug-in "give me this area at this magnification" is very flexible. When the plug-in decides that it is better to render a larger area and cache it, it can do so if it really wants to.

Ernst Lippe

On Monday 24 May 2004 09:26, Sven Neumann wrote:

Hi,

Nathan Carl Summers writes:

There are a lot of image applications that perodically update the preview. In fact, this is essentially what the gimp color balance tools do -- load a large image and adjust the sliders intermittantly and you can watch the previews go by.

Sure, but the question is if we expect the small preview area of a plug-in to behave in that way? I'd say the answer is no.

Why? The primary function of the preview is to preview the effects of certain parameters on the image. It seems only logical that the preview updates as soon as possible after a parameter change. When the plug-in algorithm is fast enough, I see no reason why the preview should not be updated automatically. The only alternative that I see is to have some separate "Update preview" button, but that is just awkward for the user.

Ernst Lippe

Agree with Ernst that it's not bad to have the preview widget hold data like other then it's physical limits : - scale
- selection limits
- ...
For instance you can have a plug-in that displays 2 scrollable previews one showing the before and one the after effect. Even nicer they could have to be synchronized(position/scale).

The way I see it :

The plug-in does the rendering(math) the preview shows it however the preview widget is controlled by the user and knows when it's time to ask the plug in for an update. If one of the rendering parameters changes the plug in should query the preview widget to get it's current view position and render. After warts fill the previews buffer and signal the preview to redraw.

1. a completely passive widget that has no other function then to visualize a preview image.
The widget would have a internal buffer where we can put the image data.
As with GtkPreview a function gimp_preview_draw_row (....) would almost be the only
visual API for a plug in developer.
- Rendering functions do not have to be changed. - only GtkPreview would change to call the new widget.

2. a more actively involved preview widget would have (1) and the basic navigation lets say horizontal and vertical scroll bars. When creating give the widget it size and the current selection limits (x1,y1);(x2,y2) one which a preview has to be made. The widget should have a signal to have it fill it's buffer whenever the scrollbar position changed. A API that returns (x1',y1');(x2',y2') depending on the scroll bars to be used in the callback function or have the values available as attributes.

- Rendering functions do not necessarily have to be changed. A call back function wrapped around the rendering function could be used.

3. This would be like 2 but also would have scaling or other features.

Geert