On Tue, 01 Apr 2003 13:59:21 +0200
Sven Neumann <[EMAIL PROTECTED]> wrote:
> Ernst Lippe <[EMAIL PROTECTED]> writes:
> > 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.
> I don't think the GimpPixelRgn API is overly complicated.
I didn't say it was, I only claimed that my current interface
> Of course an
> iterative API as I propose it needs an iterator structure but I don't
> see how this approach would be overly complicated.
Because you force the developer to write his rendering function
as a finite state machine. FSM's are difficult to read and
maintain. For really simple plug-ins this is not a big
problem, but for algorithms that make several passes over
the data this will soon become a mess. (I don't know
if there are any plug-ins that use recursive functions
but converting those into FSM's is not very pretty because
they will have to maintain their own stacks explicitely.)
Also when you discover at some later stage that a certain
function your program is taking to much time you will have
to completely rewrite plus all the functions that directly or
indirectly call it. In my API this is much easier, you
simply add the ProgressUpdater as an extra argument
and call it at the right places.
What I expect is that most plug-in developers simply don't
want to go through all this trouble. The final result is
that these plug-ins will regularily freeze the GUI.
This is really terribly frustrating, because you have
to wait until the computer is finished with computing
something that you don't want.
> > 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
> > tile.
> Exactly. This is something every good plug-in should do anyway. Most
> plug-ins already render on a tile-by-tile basis or at least do it
> row-by-row. Shouldn't it be relatively easy to make this a function
> which is called from the main-loop?
That depends on the amount of book-keeping that that function
has to do. All local variables must be moved into global
structs, all loops must be broken into separate pieces, the
code becomes less localized because related item get scattered
> > 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.
> sure, but it is usually done by returning to the main event loop, not
> by driving it manually.
As far as I can tell that is the only way that I can get GTK to process
new user actions. If that is not allowed, programmers are forced to
write all computing intensive operations as FSM's, which I would
find completely unacceptable for a GUI toolkit.
> If you do the latter, you introduce the need
> to write reentrant functions. This is usually not necessary in a
> single-threaded environment and I don't think we should put that
> burden on the plug-in developers. As you said in your document, using
> global variables is a bad habit but since you looked at some plug-ins
> you know that it is rather common. I agree that your API may look
> natural (after a much needed cleanup) but I fear that most plug-in
> authors will not understand the implications of the design.
I really did not think that re-entrancy would be a real problem. Anyhow,
it can be eliminated by a little more bookkeeping in the preview, in such
a way that at all times there is at most one instance of the rendering
function active. This will slightly reduce the responsiveness of the
preview, but otherwise I don't see any problems with this.
Gimp-developer mailing list