On Mon, 31 Mar 2003 20:17:51 +0200 Sven Neumann <sven@xxxxxxxx> wrote: > Hi, > > Ernst Lippe <ernstl@xxxxxxxxx> 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 image. 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 tile. 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 interface. 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. greetings, Ernst Lippe
