On Mon, 31 Mar 2003 20:17:51 +0200
Sven Neumann <[EMAIL PROTECTED]> wrote:
> Ernst Lippe <[EMAIL PROTECTED]> writes:
> > As promised here is my API proposal for a plug-in preview widget.
> > You can find it at http://refocus.sourceforge.net/preview.
> In the section "Design" in "Calling the render function" you state:
> A somewhat smarter version of this preview used a different
> approach. The rendering function had to call back to the GTK main
> loop, so it could process new events.
> I wouldn't call this a smart version since this is something that you
> better not try to implement. Why do you want to drive the GTK+ main
> loop yourself? This only leads to really complicated behaviour (as you
> seem to have experienced yourself). The easiest approach to this
> problem seems to be to split the rendering function into small
> chunks. Instead of calling some function that processes events, the
> render function returns after computing a small tile of the preview
> image. The standard GTK+ main loop takes back control, user events are
> processed and if it ever becomes idle again, the list of invalid tiles
> is examined and the render function is called with the next area to
> update. Did you consider this approach?
Yes, and I did not like it.
One of the goals for this preview was that it should be easy to use
the same function for rendering to the preview and to the final
In many cases it is not too difficult to convert an existing
rendering algorithm so that it will only render a specific
area of the final result.
But many plugin algorithms have a considerable setup time, which
means that there is a lot of overhead when you call the rendering
function for each output tile.
The only way to avoid this overhead is to make interface more
complicated, analogous to the GimpPixelRegions, there should
be an _init interface that the preview uses to inform the plug-in
about the total area that it wants, and a _render_tile interface
that tells the plug-in that it should render a specific tile.
If you want to rewrite an existing rendering function to this
new interface you will have to make major changes. (Essentially
this is very similar to the steps that you have to make when
you want to change a recursive function into an iterative function.
It is always possible, but the results are generally completely
unreadable.) Basically, what you will have to do is to record
local variables in functions in some global structure, and
to retrieve these values when you have to compute the next
To summarize, if the preview should ask the plug-in to render
individual tiles (and when the preview is zoomed out or when
the preview is large there can be a large number of tiles
that must be rendered) it will either be inefficient for some
plug-ins or plug-in authors will have to implement a complicated
As a plug-in author, I believe that my proposed interface is
very natural. I have already converted a few plug-ins and
that was fairly straight-forward. I definitely would not
like having to rewrite those plug-ins in such a way that
they could efficiently compute individual tiles.
Also I must say that I am a bit disappointed that calling the
GTK main loop is so expensive (or that there apparently is
no other way to process new GUI events). Giving control to
the main event loop at regular intervals during computations
is a standard solution to avoid freezing of the GUI in
cooperative multi-tasking systems.
Gimp-developer mailing list