On Tue, 01 Apr 2003 13:59:21 +0200 Sven Neumann <sven@xxxxxxxx> wrote: > 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. I didn't say it was, I only claimed that my current interface is simpler. > 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 everywhere, etc. > > 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. greetings, Ernst
