On Saturday 22 May 2004 22:40, Nathan Carl Summers wrote: > On 22 May 2004, Sven Neumann wrote: > > So this API would allow you to queue a redraw even after the buffer is > > only halfway written. Of course you would also have to run the main > > loop for the redraw to actually happen. Anyway, I consider this rather > > bad style. IMO, if the preview takes considerable time, then it > > shouldn't be shown halfway done but instead the progress API should be > > used to draw a progress indicator in place of the preview. What do > > others think? > > There are a lot of image applications that perodically update the > preview. In fact, this is essentially what the gimp color balance tools > do -- load a large image and adjust the sliders intermittantly and you can > watch the previews go by. There are good arguments for incremental > update, and good arguments for a progressbar. For very slow plug-ins incremental updates are better, because the user can sooner detect and remedy any problems with the parameter setting or the correct scroll position sooner. It is especially useful during scrolling because it is frequently possible to determine from a small part of the new image if you are at the desired position or not. When the preview image only shows a progress-bar you loose this type of immediate feedback. (In my current version of the preview incremental updating does not work, even though I call gtk_widget_queue_draw on it. Like Sven indicated, I would probably need to call back to the GLib main loop) > But I think the real issue here is that slow previews should be computed > in small chunks in an idle handler so as to not impede interactivity. Another very important issue is how these computations can be halted when the image that is being computed has become obsolete. In my experience this happens very frequently. Ernst Lippe
