Hi, Dave Neary <dneary@xxxxxxx> writes: > I'm not sure what you mean by this - wouldn't the preview just be a > copy of the drawable which gets rendered? What API is needed? I have > trouble following the problems you see. I'm a bit confused now since we discussed all details of the widget several months ago. It might be worth to dig out that discussion again because it had a very good list of requirements. The main point is that of course since you want to preview a plug-in's result, the plug-in shouldn't have to run the complete drawable thru whatever pixel manipulation routines it applies. There wouldn't be a need for a preview widget then, you could simply apply the effect. The preview widget needs to be smart enough to cause only the visible area to be processed (from an idle handler so that the GUI remains responsive). For a zoomed preview it needs to pass scaled data to the plug-in's pixel manipulation routines which may then have to adapt to the scale ratio that is applied. Ideally the same pixel manipulation routines of the plug-in should be used for rendering the actual result on the drawable as for rendering the preview. Since we don't want to introduce major changes to the plug-in, the preview API should probably provide a fake drawable that the plug-in can work on. Sven
