Hi, Ernst Lippe <ernstl@xxxxxxxxx> 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. 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. > 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? > 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. well, rewriting some plug-ins to operate on tiles would be a major win but I agree that it is nothing we want to do that this point in time. > 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. 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. Salut, Sven
